DevOps Series - CI/CD: understand its concepts and principles

Have you ever wondered how long it takes to ship software to production? Months? Weeks? Days?

A growing number of companies are doing it in a matter of minutes. That's right, in minutes. And that's only possible with the help of CI/CD (Continuous Integration/Continuous Deployment). But what exactly does that mean? How does it work?

Before CI/CD, let's understand what pipelines and jobs are

Before getting into the concept of CI/CD, it's important, within this context, to understand what pipeline and job mean.

Pipeline, translated literally, means plumbing, and it really is an analogy to physical piping. In DevOps practices, it's a list of actions, usually called jobs, where the output of one action is the input of the next.

Thinking of a real-world scenario, we'd have something like a first job to install dependencies, a second job to run code validation, a third to run tests, a fourth for the build, and finally the deploy.

You can also organize by stages, which are nothing more than a set of jobs in the pipeline. Thus, a test stage, for example, is understood as a set of actions that run unit, integration, and end-to-end tests.

Finally, for a pipeline to start, there must be a trigger — or trigger, for those who prefer English. This trigger can be a push of a code change to a specific branch, or a merge, for example.

CI - Continuous Integration

Continuous Integration, or continuous integration, is a practice in which a development team integrates its code very frequently. Since this integration activity consumes quite a bit of time and effort, teams look to automate everything possible. This automation is done through tools that run the necessary steps (dependency installation, tests, compilation, etc).

The main goal of CI is to establish a defined lifecycle that reduces the effort required to integrate code. Continuous integration also results in errors being caught while the code is still in its early stages. CI is normally divided into the push, test, and fix stages.

Push: When working on software as a team, it's important that your code is pushed to the remote repository and integrated with the other work as quickly as possible.
Test: CI should have a stage of reliable automated tests. These tests must validate the code that was developed. Ideally, unit tests are run first and integration tests afterward.
Fix: If a problem is spotted, fixing it should take priority over adding a new feature. The whole idea is to always have code ready to ship.

Benefits of Continuous Integration

Reduced integration risk: developers are often working on separate or complementary tasks, which brings a certain level of risk to integration. Integrating frequently minimizes this kind of problem.
Higher code quality: with the help of a code validation stage, it's possible to focus more on the code's functionality, which results in a higher-quality product.
Versioned code works: all code versioned in the main repository must be functional. With CI, it's possible to identify whether there's a problem that needs to be resolved for the software to keep working.
Shorter deployment time: automating the integration process reduces the time it takes to deploy the software.

CD - Continuous Delivery

Continuous Delivery, or continuous delivery, is the practice of ensuring that code is always in a stable, deployable state. This means that all code changes, new features, and bug fixes must be ready for deployment to a production environment.

The goal of CD is to make the deployment process available on demand, at any moment. Regardless of the deployment's complexity, whether in a distributed system or a simple monolith.

At this stage there's also the concept of Continuous Deployment, or continuous deployment, which is nothing more than the next step beyond continuous delivery. Continuous deployment is the end goal of development teams. In addition to ensuring the software is ready for deployment, it is also released to the production environment automatically. Unlike continuous delivery, there is no final manual approval step before it goes to production.

Principles of CD

Repeatable and reliable process: to make deployment easier and ensure quality, it's important to use the same release process for every environment (development, staging, and production).
Automate everything: everything should be automated, which prevents as much as possible problems caused by human error, such as a wrong environment variable.
Continuous improvement: this is the most relevant of the principles. It ensures you keep up with changes and evolve your processes.
Everything must be versioned: code, configuration, scripts, databases, documentation, everything must be versioned! This guarantees a stable foundation for building processes efficiently.
Everyone is responsible: "it works on my machine" shouldn't be a valid excuse. The team's responsibility must extend to production. Everyone should share responsibilities throughout the entire process.

CI/CD tools

Of the many tools available on the market today, I've highlighted the main ones used day to day.

Gitlab: a DevOps platform. It integrates all the functionalities needed for the software development and delivery process.
GoCD: an open source tool that automates the CD process. It features value stream mapping, native cloud deployments, workflow modeling, and traceability.
Docker: a set of tools that lets you run the steps of a pipeline as well as ship software in packages called containers.

Conclusion

All in all, CI/CD improves the speed, productivity, and sustainability of the software development team. The team can focus on responding more quickly to market changes and evolving the software, while having fewer tedious and repetitive tasks.