CI/CD in a nutshell

CI/CD is a popular practice that many companies and projects use today. However, sometimes we use these terms mistakenly, but in this article we'll dive into the CI/CD fundamentals, understanding the problem that these practices solve as well as analysing how they fit in today's cloud architecture.

🔥 Merge hell

In the early days of software development, developers used to merge their work with less frequency. It was a manual job, so once a month usually, developers would sit together to merge everything they worked during the month.

Resolving conflicts was a real pain, not to mention performing tests against a ton of built features. Moreover, deploys and rollbacks used to come with a hell of problems, that's why they call this process the merge hell.

🙏 A new hope

New ideas arose to overcome this problem. Instead of merging work once a month or even worse, developers should merge work more frequently, almost daily, why not multiple times a day.

The work is merged in the main branch as soon as possible, and upon such a merge, we should ensure the integrated source code has quality, security and correctness.

These traits are performed using code style checker (linter), security checks and a good automated test suite.

This process has a name and it is called continuous integration, or CI.

How can we run a CI process?

Because we work on teams with multiple people sharing a remote Git repository (i.e Github), we can run our CI wherever we want.

Could be our computer? Yes.

In the above picture, we see a CI scenario where we pull the code from a remote repository (integration sync, fetch + merge) and then we perform the needed checks on our own computer.

But we better run it in the cloud, right?

☁️ Running CI in the cloud

The process of running CI in the Cloud could be implemented as follows:

• Code integration: the code repository runs in the cloud using some version control system (Git), for instance Github, Gitlab, etc.

• Code quality, security and correctness: at every change, before going to the main branch, some computer or VM in the cloud should checkout the code from the repository and perform style/security checks and perform automated tests.

Many companies created CI tools in the cloud so we can use them to run our CI system. Big players specially Github and Gitlab employ their own CI tools along with code repository (Git) in the cloud.

But there are other tools in the cloud such as CircleCI, SemaphoreCI to name a few, that employ only the CI tooling.

All these tools are paid somehow, we can use them for free but in case we increase the usage, they can be expensive eventually.

🚀 Delivering the application

Okay, it's all good with the "continous integration" part. We have a good CI system in the cloud and we might pay for it as we increase the usage.

But how do we deliver the application?

Assuming all the CI checks have been finished sucessfully, we can build/package our application in a newly generated version and deliver it to production, changing the old application to the new one, right?

First, let's say we build the application using our own machine:

After building, we should send (push) the package to some sort of "package registry" in the cloud, from which the infrastructure in production will fetch (pull) the new package and "roll out" from the old package to the new one.

This process of updating the application in production is called deployment, and all the process of building/packaging and ensuring the newly version is deployed in production in a sustainable way is called continuous delivery, or simply CD.

How about offloading the CD process to the cloud, same as we do in CI?

This picture is very common nowadays, many projects are integrated and delivered using the architecture above. Tools such as Github and Gitlab play an important role employing CI/CD for startups and enterprises.

❤️ Community matters

The process of integrating and delivering an application is so common that many people and companies across the world joined together and created a non-profit open-source community called Continuous Delivery Foundation, or CDF, that aims for incubating and graduating open-source projects that employ CI/CD systems in a sustainable way.

This community is driven by the same values of other communities namely Linux Foundation, Apache Foundation, Cloud Native Computing Foundation (CNCF) etc.

I hope you enjoyed the reading. In the upcoming posts, I'll be talking about Tekton CI/CD, which is a graduated CDF project, and how this open-source tool helps delivering cloud-native applications in the cloud.