1–10 of 32 posts
What are you using? What criterias did drive this choice? Would you do it differently?
GitLab's CI has a pipeline design, so (like Jenkins) you can have some jobs wait for other jobs to complete and use their build artifacts (e.g. have a single build job that downloads deps and compiles everything so later jobs don't need duplicate that work), and you can have jobs only be triggered manually instead of on every push.
It's not perfect, though. For instance, unlike TravisCI, you don't have a build matrix, but you can use YAML tricks to define template jobs (see GitLab's own CI file [0] and a resulting pipeline [1]). If you use GitLab.com, you should be aware that they have downtime a few times each month, both planned and unplanned. For their planned downtime, it is often during the work day in the US timezones, and usually lasts between 10-30 minutes (though it has been longer before). GitLab.com is also used as a "testing in production" environment for their monthly releases, so you will occasionally run into bugs (usually nothing showstopping though; mostly minor annoyances).
I think that what you choose greatly depends on what you need. GitLab CI is a little opinionated, but it is still pretty flexible and usable for a large number of work cases. If you need a ton of customizability, Jenkins could be a better option (with plugins). GitLab CI is a lot easier to setup, however.
GitLab CI also has CD features that you can look into (I don't use them myself). They are also constantly (i.e. every 22nd of the month) releasing new versions, and most of their features are open source.
[0]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-...
[1]: https://gitlab.com/gitlab-org/gitlab-ce/pipelines/6014043
Biggest lesson for us: Avoid putting all your logic into Jenkins templates. You're not capturing your CI/deployment logic in version control, and this can cause problems down the road (we backed up Jenkins regularly, but versioning was a weak point).
Instead, do as much as you can in scripts, and use Jenkins as a glorified crontab (+webhooks).
Jenkins is okay but you have to really stay on top of the build environment (not just a specified in Jenkins itself but also the OS and tooling on the Jenkins server and build machines).
I'm in the process of building a new CI/CD pipeline and this time I'm using Concourse. This is a good fit because the target system is largely containerised (not that Concourse can't be used elsewhere, it can, but it's just a coincidental fit). Additionally, Concourse addresses the problem identified by Cpoll as, unlike Jenkins et al, Concourse pipeline, build plans, and tasks are 100% available for version control.
That all said, I can't comment on Concourse's foibles as I've not used it long enough to uncover them :)
We use Jenkins, hosted on Amazon. We're .NET stack, so some of the other options didn't work. Biggest lesson for us: Avoid putting all your logic into Jenkins templates. You're not capturing your CI/deployment logic in version control, and this can cause problems down the road (we backed up Jenkins regularly, but versioning was a weak point). Instead, do as much as you can in scripts, and use Jenkins as a glorified c…
Jenkins Job Builder[1] is a great tool that solves exactly this problem. You write job definitions in yaml/json files. Then, check these yaml files into version control and run JJB to push these jobs to your Jenkins server.
JJB is great because it's purely a client. It requires no extra Jenkins plugins. Since all of your jobs are now captured in version control, you can reproduce your Jenkins jobs instantly in a local docker container or vagrant machine to dev/test change to your Jenkins jobs.
I really recommend trying it out. No more manually clicking around in Jenkins to configure things.
We use Jenkins, hosted on Amazon. We're .NET stack, so some of the other options didn't work. Biggest lesson for us: Avoid putting all your logic into Jenkins templates. You're not capturing your CI/deployment logic in version control, and this can cause problems down the road (we backed up Jenkins regularly, but versioning was a weak point). Instead, do as much as you can in scripts, and use Jenkins as a glorified c…
We've found the Job DSL plugin pretty useful for backing jobs up. https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin