Why do we need Continuous Integration?

Tech companies will have quality criteria that need to be met before accepting code in their code base. For example, unit tests need to pass, code coverage should be at a certain percentage and so on. Leaving adhering to this criteria to the developers is an error prone process and just not a good practice. 

For instance, a developer may forget one of the criteria, or might even do that intentionally because they have poor work ethic. This is where Continuous Integration comes in. It’s a safeguard that ensures all the code added to the code base in the version control is of accepted quality through automating the enforcement of quality gates.  

But what exactly is CI, and why is it so crucial in modern development workflows? Simply put, CI is the practice of frequently integrating code changes into a shared repository, followed by automated builds and tests.

Understanding Quality Gates

Quality gates in CI are checkpoints that code must pass before moving to the next stage. While these gates assure code quality, it’s essential not to depend on them entirely. As DevOps expert Mohamad Radwan suggests, fostering a culture of quality is vital. Developers should work hard to meet quality standards before the CI process even begins.

What are the steps of the Build Time (CI)?

1. Download the source files:

We will start with downloading the source code. Usually the source code resides in a version control platform so this is the time it takes to download it depending on its size, latency, how fast the network is etc.

2. Restore dependencies:

Modern software development depends heavily on third-party libraries, such as .Net’s Dynamic Link Libraries (DLLs), which, together with critical configuration files and environment variables, form the core of an application’s functionality.

3. Compile the application:

Compiling means taking the source code which is written in a programming language that humans (or some of them to be specific!) understand and convert it to a language a machine can understand such as machine code or intermediate language (IL).

4. Other tasks:

 This include ensuring quality, Bundling and minification, versioning the application, running the unit tests, calculating the code coverage, running code analysis, measuring technical debt and code smells, creating code documentation, packaging artifacts, storing packages in repositories among others.

Manual Build Vs Automated Build

As a general rule of thumb, when we are studying an automated process it’s always good to study the manual process that we are trying to automate. The reasoning is simple here; without understanding the manual process we won’t be able to see what’s going on under the hood and we will limit our abilities to troubleshoot when things go wrong (and they will according to a wise man named Murphy!).

Let’s say that we have unreasonably long build time in our pipeline. Without knowing what the build consists of we won’t be able to pinpoint the cause of such delay. But when we know exactly what’s going on in our automated build we can go and examine each step and find where the issue is coming from.

Now let’s examine the difference between manual and automated build here:

Manual Build: 

Our developer, let’s call him Adam, does not trust all these automation “fad” everyone talks about, and wants to do his business the traditional way. So, he pulled the latest code from his company version control which happens to be hosted in GitHub manually. Then, he restores the required dependencies which happened to be stored in Nuget and builds his project using visual studio. After that, he ran his unit tests manually to confirm the company’s quality criteria.

Automated Build:

Our second developer, Nuha, has a more accepting attitude of new innovations. She knows better than to follow every new trend but also can see the value and importance of automating repetitive tasks so she follows the recommended best practices. 

Nuha writes her code and she commits to the version control (GitHub) which triggers the automated build. Nuha uses Azure devops but any other tools such as Jenkins or Github Actions work as well. These tools take care of restoring the dependencies, compiling the code, running the unit test and ensuring the quality of the code and eventually producing the build artifacts.

Why is automated build better?

Dear reader, I know you are a smart person. The mere fact you are reading these lines confirms this! So I am sure you concluded that automated build is way better than manual build. 

But let’s think about why it’s actually better? Saving time is a big plus. Automated builds are way faster and more efficient than manual builds. Moreover, consistency is good. Actually, having a consistent environment where you do all of your builds gets rid of the notorious problem of “ but it works on my machine” which makes everyone’s life easier. 

Another good point for automating the build is its ability to scale with team size and project complexity which is an important consideration from the business point of view. Lastly, but not least is quality assurance that automated testing provides. 

In my next article I will discuss the nitty gritty details of CI such as build agents and the anatomy of CI pipeline. Stay tuned and thank you for reading this far!

References:

Radwan, Mohamed. “Managing Version Control.” Fundamentals of Modern Software Engineering and DevOps course, Module 7. DevOps Visions, https://learn.devopsvisions.com/. Accessed on 12th December 2023.