CI/CD environments, why I have chosen Jenkins

Bo Bracquez
3 min readDec 11, 2019

--

The medium placeholder when writing a new story says “Tell your story…” and this is exactly what I am going to do. This might be slightly biased but I am trying my best to stay as neutral as possible in my way of thinking.

What is a CI/CD, is it dangerous, will it eat me alive?

Fear not, CI/CD will not you alive! Or it might… who knows!

CI/CD stands for continuous integration and continuous delivery. That’s a lot of long words… To explain this in a simple fashion it is basically a practice of making sure that the latest code, which has been committed or ‘uploaded’ to the code repository, is compiled and running on a live system.

This means that if I make a change to the code, commit and push it to version control then an action will be triggered that will execute a bunch of predefined steps. This includes building the project from a clean slate/state, copying over configuration files. You can also extend this by including unit tests, database seeding etc. When the job is completed then your program will be deployed to the configured system and it will be up and running in no-time! You can also include some nice integrations with Microsoft Teams, Slack, custom webhooks etc for notifications etc for your team. Now your project manager no longer has to bother the devs by asking when something was deployed. It’s just like black magic!

Source: https://blog.gds-gov.tech/that-ci-cd-thing-principles-implementation-tools-aa8e77f9a350

In a CI/CD environment you are also able to make different configuration for different ‘environments’. This way you can have a dev, test and production environment. Every environment will often live off seperate brances in your git repository.

However, for some people it might seem a bit over the top and too much… I do not directly disagree with you but these are just tools to aide development and streamline it. It is all up to your team or yourself if you want to use it.

Source: https://xkcd.com/974/

The products on the market

There are a lot, and when I mean a lot I really do mean a lot, of different products on the market. Take a look at the infographic below.

Source: https://dzone.com/articles/what-cicd-tool-should-i-use

And this is not everything that’s available! It is so hard to start to pick something out of this massive pool. This is where I decicded to put up some requirements, and this is where people might start to disagree.

  • It has to be free as in beer (no licensing cost and I am not selling my data)
  • I need to be able to create addons/plugins easily (open source maybe?)
  • Can run in a docker container out of the box (just to save us some time and frustration with configuration).

My choice and motivation

These requirements reduced a lot of possibilites and I thought it might become hard to find a solution that worked for me. Things like Azure, Google Cloud and the like were out of the question, they are not free (even though you can get free credit, I did not want to rely on it). Products as from Atlassian (Bamboo) were also out of question due to it being paid (in order to get the source code).

My final choice was between GitLab, Jenkins and TeamCity. They all have Docker support, are free etc. But then I wanted to add the ‘open source’ requirement and there goes TeamCity… What’s my final choice? GitLab? Jenkins? I went for Jenkins… They do not have features locked behind licenses and I do not want to be suprised at the end of my project with “oh I need to buy a license now”.

Jenkins just ticked all the requirements I needed and I was happy to settle down with my choice after a my long research.

--

--