Today, CI/CD is reportedly used by up to 90 percent of professional programmers. No wonder. Continuous integration and continuous deployment basically only have advantages. In bart, we use them on every project, in one form or another. Why? Because we care about improving the quality of our work.
First, a bit of theory. Continuous Integration and Continuous Deployment (CI/CD) is a set of software engineering procedures. In particular, they introduce minimization of contact of real people with testing and deployments. In short, developers are replaced by more efficient, faster and more reliable automation. The CI part usually involves automated code checking at each commit, and the CD in turn continuously deploying to a live environment after each change, not only for large features. What are the benefits?
-
Nicer code
Our CI/CD procedure is set up in such a way that every time the code is merged, it automatically passes through a pipeline, which is a system consisting of several tasks/jobs. These include formatting check, static analysis and test build. Thus, a new contribution to the project is adjusted to match the rest, and only real changes and real conflicts, not differently used indentations or unnecessary variables, appear when merging. This simplifies the merge itself and ensures clarity of the project.
-
Fewer errors
A series of simple units and integration tests are also carried out as part of merging. We call them “cheap” because the testing process itself takes only a few minutes and therefore doesn’t take up many resources, and therefore doesn’t cost much money. Unit tests only test individual functions or small pieces of code without external dependencies. The integration ones check how components communicate with each other within a single system (e.g. API, FE or microservice). By running these tests immediately after the code commit, the programmer can immediately return to their feature and fix the code. If they were launched only a day, two or three later, or only when deploying, it’s possible that the developer wouldn’t even remember what and how they did it, and the repair would be more difficult for them.
Sometimes we also use the so-called end-to-end tests. However, they aren’t run on every commit, but regularly at intervals, before the build moves to testing or before a feature is deployed in production. These tests last for several hours and require all services and browsers to start to automatically “click” instead of the user. Although they’re much more resource intensive, it’s definitely worth starting them before deploying.
Thanks to the right combination of cheap and expensive tests, we can catch most errors and fix them in time. This makes the entire project safer, as we prevent bugs from being transferred to the production environment and thus reduce the risk of problems that would be discovered by the user.
-
Faster development
Since all the tests and checkpoints in the development process are automated, we don’t waste “human” time on them and we have space to think about the things that are important. For example, communicate with the client more, address changes in their requirements or experiment and try new functionalities. Thanks to this, novelties make it into projects that we wouldn’t even start to develop without CI/CD. There would be no time or will for that…
-
Better control
Frequent integration also means that from time to time we only add about 10 lines of code to a project. We can check such a small code properly during deployment, immediately resolve any conflicts and deliver the update to the customer faster. If we were to merge only after completing all the great functionalities, there would be significantly more lines of code. A lot of reading usually means reduced attention. After the first thousand lines, the programmer usually resigns, marks the merge request into the project as, figuratively speaking, LGTM (looks good to me), proposes solutions only for the most critical errors and considers the work done. Shorter code means better quality control and therefore, of course, a better product.
5. Cost reduction
This advantage is, as always, debatable. Of course, setting up processes and writing tests requires programming time, and a lot of it. However, considering how much money this investment will ultimately save us, it’s certainly worth it. Plus, fewer errors in the code means less time spent fixing, which equals more savings.
In my opinion, the CI/CD development elements pay off even on really small projects. For example, pipelines are available to virtually every programmer, because GitLab offers their launch in its free tiers. This way people can feel them, test them and evaluate their usefulness. Especially if they don’t want to manually build, wait, then check and fix and then do it all again. Of course, you have to consider what’s worthwhile and what’s not. No procedure is universal or effective for everything.
And for large projects with multi-person teams? If we want to develop well, CI/CD is almost a necessity here. Every person is at risk of making a mistake that the program simply doesn’t make. So let’s leave creative work, inventing and analyzing to people, and let the machine/AI do everything else. This is how we complement each other greatly and develop truly high-quality digital products.
