In software development, continuous integration is the method used for keeping the main source code (commonly known as the main branch) in a stable condition. Why one would try to achieve this goal is obvious. Non-working code is not that useful, and it can be quite a costly endeavor to fix it. How to avoid this and create as optimal code as possible has become its own branch of software engineering, and in many cases, there’s an entire team working on achieving this goal. Now, this goal can of course be achieved in different ways, and often, development teams have their own way of working. In this article, I will give you some insight into some possible ways to go about it.
In my experience, a must-have to achieve this goal is to practice Continuous Integration (CI). There are multiple techniques regarding how to apply CI, and the most suitable approach will of course be contingent on the specific context in which CI is utilized. However, there are some fundamentals that I believe should always be applied.
Everybody working on the code should always have the most recent copy of the main branch in their development environment as easily accessible as possible.
All changes to the main branch should be as minimal and atomic as possible.
Use a pipeline to ensure that the main branch is as stable as possible.
If the main branch breaks, it needs to be addressed right away, and it should be easy to revert to a previous version of it.
One thing that I think is important to clarify here is what a pipeline is and its importance.
A high-quality main branch is the means and end of CI and, in my view, the most effective and easiest way to achieve this is by using pipelines. But what exactly does a CI pipeline do? Well, typically it listens to changes in the codebase (not necessarily just the main branch) and triggers builds. It then runs various quality assurance tests on the codebase. This may sound complicated but the good news is that there are a great number of tools available today for the job such as Jenkins, CircleCI and Github Actions to name just a few.
It is totally up to the owner of the project when the pipeline should be triggered and what it should do then. However, as the main purpose of this is to keep the main branch stable, every change to it should go through the pipeline. Furthermore, the pipeline could be configured for various other things as well (see example under “Continuous Deployment/Continuous Delivery”). As a final note, the importance of a strong and reliable test suite cannot be understated when using a pipeline. Simply put, bad test = bad pipeline.
To kick things up a notch, let's look at Continuous Deployment/Continuous Delivery. Continuous Deployment refers to the practice of automatically releasing the software when it passes certain tests. Since we are now in the realm of breaking production, you need to be somewhat cautious. If we let a bug slip past our test suite, it may cause severe problems. Therefore, a robust test suite is absolutely crucial. In my experience, the more sensible approach is to use Continuous Delivery instead. The difference between the two practices is that with Continuous Delivery, we do everything we do in Continuous Deployment, but we also need human approval for any releases to production. This is a perfect opportunity to do manual testing or user testing with a test group to ensure that what is in production is of the highest quality. How do we do all the above? You guessed it, pipelines! We can simply add a new pipeline or reconfigure the current one to run deployment scripts as well. In the same vein, Continuous delivery does the same, but instead, it listens to human triggers to start running.
To wrap things up I will leave you with some final thoughts. The first one is to strongly encourage the reader to use CI/CD as early as possible in almost every project. With the tools available, it is easy to start practicing CI/CD, and the time you will save on quite a tedious bug hunting and frustrating debugging is in my experience always worthwhile. Secondly, invest time in a strong test suite. I would recommend this to every reader regardless of your use of CI/CD. Lastly, when using CI/CD, the return on your investment will be greatly amplified, and you and everyone working on the project can spend more time on the most rewarding part of software development: Implementing cool and exciting features!