A comparison between Gitlab CI and Concourse CI
Recently I migrated a few repositories from Gitlab to Github. Prior to that, I used Gitlab CI heavily to run CI jobs whenever we have new commits or merge requests to those repositories, and now I have migrated them into Concourse CI. This is an interesting journey and I would take the chance to share my takeaways for those two completely different CI systems.
Gitlab CI
Gitlab CI is a CI product that is builtin to Gitlab, the unique position brings it a few essential advantages:
- no worries about how to checkout code from the repo — no secrets management, permissions etc
- no worries about how to trigger builds, no matter it is for the pipeline of a specific branch like ‘master’, or for pipelines for merge requests
- once you configured some “global workers”, CI jobs for all repositories (including newly added ones) will automatically utilize them if possible, which means there are no further configurations for new
- you set up only worker nodes, which don’t have to be highly available. The highly available master node is Gitlab itself which is already taken care of
It also comes with some really nice design elements:
- it uses one single intuitive .gitlab-ci.yml file to describe the pipeline
- you have a nice pipeline graph for your CI run
- you have default notification when your pipeline fails
It is super simple to add a new pipeline to a Gitlab repo. It works extremely well for smaller projects.
Concourse CI
Concourse CI is a standalone CI service which has a quite novel design. It abstracts everything into either “Resources” or “Jobs”. When jobs represent the calculation which aligns to our traditional ideas about CI, resources is a very interesting concept that represents the external world and external states.
Concourse CI has some unique features as well:
- Its pipeline graph shows clearly the relationships from a job to external resources, this makes the pipeline graph much more reasonable
- It has no plugins. In order to extend the capability of the system, you will need to implement a new resource type, which is as easy as creating a docker image that contains 3 binary files in /opt/resource/check, /opt/resource/in, /opt/resource/out, the docker image will be initialized and handle calls from Concourse Server
- It enforces pipeline as code practice, web UI is for viewing/triggering purposes only
- It has an elegant way to manage secrets
- It has strong isolation by default since all jobs are running in containers
It takes some time to get used to Concourse CI. But once reached the point of proficiency we’ll find it to be very flexible, with ultimate control over the things you want to do. Then we’ll enter a world of applying many pipeline patterns.
Here’re some common patterns you may find handy later:
- Applying a global capacity https://gist.github.com/bencao/f3ea0c490d1733cd5cf67c38d3550451
- Time triggered pipelines https://github.com/pivotalservices/concourse-pipeline-samples/tree/master/concourse-pipeline-patterns/time-triggered-pipelines
- Gated pipelines https://github.com/pivotalservices/concourse-pipeline-samples/tree/master/concourse-pipeline-patterns/gated-pipelines
The list of patterns can go on and on. There’s no limitation.
Both Gitlab CI and Concourse CI are excellent CI products. I would advise you to choose wisely based on your concrete use cases.