In work we use Jenkins to manage our builds, this includes build, tests and packaging for Java, Go, Ruby, IOS and Android as well as various ad-hoc jobs.
My colleague pointed out that Jenkins is probably the only tool we try and use as one size fits all, anywhere else we have greater freedom to choose the right tool for the job.
I'm interested in which CI tools people are using and why you're using them. Are you using specific build tools for certain technologies or one for all?
Are you using pipelines as code? How do you control which versions of plugins you use (i.e. how can you give users the freedom to complete their tasks without having to raise a ticket for another team to add/upgrade a plugin)?
Top comments (3)
I formerly used (and administrated) my own Jenkins instance, mostly because at this time, there was no credible alternative.
I used it to build a PHP app, to deploy it on a staging server, and to run integration tests.
Now, my company hosts a gitlab community edition instance, and that's a big step forward compared to Jenkins. Now I have not only a CI tool, but also a git host, an issue tracker, a kubernetes instance, a mattermost instance, and this is all connected!
Of course, this is not specific to gitlab, but this kind of environment is a big improvement in a dev life. If by pipeline as code you mean having a file that describes the pipeline in the codebase, yes, I have it (.gitlab-ci.yaml).
The only drawback is that I'm dependent of the support team for the plugins.
I've used Jenkins at 2 companies now. One jenkins instance was managed by a systems engineering team, and was supporting about 5 product teams with about ~250 jobs on it. All the jobs were configured manually, and the build agents were some desktop machines running out of the back closet. These built Android, Java, Ruby, JS apps.
At my current company we have a few different patterns. One is a Jenkins master with auto-scaled build agents running on EC2 managed by an internal tools team. Its got about 400 jobs building and testing containers, chef cookbooks, js, ruby. This supports about 8-10 teams.
The build agents are a generic AMI with multiple languages and runtimes installed on them. We then started relying on the automated tool installer plugins since they integrated neatly with Jenkinsfile. Jenkinsfile has been getting a lot more use as a pipeline-as-code tool, and the ability to run jobs inside of docker containers simplifies your build agent configuration so much. It generally doesn't do any deployments to production, so permissions are lax and the dev team is trusted to install whatever plugins you need. Sometimes things break, but its never that bad.
Theres one team with a Jenkins master hosted on EC2 with a Mac mini as a build agent for building/signing iOS apps. There's a another group of teams that each manage their own Jenkins master instance hosted on EC2 (~5-10). Theres another group of teams using AWS CodePipeline and CodeBuild for terraform and lambda builds/deployments. The open source stuff uses Travis.
Love me some GitLab CI. It's integrated tightly into their platform, and configuration is fairly straightforward. I've been using it for years to deploy simple static sites or fleets of microservices.