Continuous Integration in DevOps

What is Continuous Integration in DevOps?

So far we have covered Part 1 and Part 2 of this topic in our previous sessions and currently in Part 3.

Till part 2, we covered about the people and process aspect of DevOps, which is collaboration and focus on the common goal, common mindset and common thinking in the team that helps to achieve the objectives of DevOps. In our last tutorial we gained knowledge on How to Develop Collaboration in DevOps.

                      Check out => Ultimate Guide on DevOps

Continuous Integration, Continuous Testing, Continuous Deployment and Continuous Delivery are the main technical aspects of DevOps.

VIDEO Part 3 Block 1: Continuous Integration – 12 minutes 20 seconds


In the last part, we have learned practices of DevOps under which we learned which parts of agile principles are adopted by DevOps practices.

How are the objectives of DevOps achieved through these principles?

We have studied the importance of Version control, Automation and delivery of small increments of value to customers and its benefits.

What is collaboration in the context of DevOps and how do we achieve it?

So far we spoke about the people and process aspect of DevOps, that is collaboration and focus on a common goal and common mindset and common thinking within the team that helps to achieve the objectives of DevOps, now let us learn about few technical aspects of DevOps, which makes a DevOps release possible.

They are continuous integration, continuous delivery and deployment and continuous testing.

As part of block 1 of part 3, let us first study ‘Continuous Integration’.

What is Continuous Integration?

Continuous integration -> CI ->set of processes ->Build pipeline/CI Pipeline

Continuous Integration, shortly called ‘CI’ in DevOps is an important process or a set of processes which is defined and carried out as a part of a pipeline called ‘Build Pipeline’ or ‘CI Pipeline’.

We know that in the DevOps practice, we have a single version control tool for both Development and Operations team, where everyone’s code will be deposited as a master code base and this allows the team to work in parallel.

So, Continuous Integration, in DevOps is nothing but merging individual developers code into the master copy of the code to the main branch where version control is maintained. There is no restriction on no of times for the code merge that needs to happen in a day.

As and when the developer checks in their code to the version control, immediately the process of CI kick starts.

The CI process includes,

  1. Merging of all the Developers code to the main line,
  2. Triggering a build,
  3. Compiling the code and making a build and ….lastly
  4. Carrying out the unit test.

So, Continuous Integration is a process of merging all the developer’s code to a central location and validating each one of their merges with an automated build and test.

To explain technically what happens during CI is,

There will be a server for continuous integration which hosts the CI tool, which keeps watching the version control tool for the code check-in and as soon as, a check-in is found, it triggers the automated compilation, builds and runs unit testing along with static code analysis and a basic level of automated security testing.

The various tools to carry out the automated testing, like Jenkins, TestNG, NUnit to carry out unit testing, Sonar to carry out static code analysis, and fortify to carry out the security testing, all of these tools will be integrated with the CI pipeline.

So, the complete CI pipeline is an automated process without any manual intervention and runs within a few seconds or minutes.

So, the major benefit of the CI is the rapid feedback that the developers get within no time.

  1. The CI runs after developer checks in the code and throws out the results in seconds. So, it allows the developers to know immediately if his or her code has successfully built or broken.
  2. It also lets the developer know if his code has successfully integrated with the other’s code or broken, that something that another team member has done to a different part of the code base. Hence, CI does the quicker code analysis and makes the later merges simpler and error free.

So CI is an automated process, where the build gets triggered with every code check-in, gets compiled, creates build and automated unit tests are run on the build.

We can also call CI as the COP or process of checking if everyone’s code in the team is a good or valid code or not, because CI process, immediately compiles and builds with each check-in and throws errors if it is a bad code, or it cannot be compiled or cannot get through the automated unit test cases.

What are the Benefits of CI?

First of all, the entire CI process is an automated process and hence minimizes the human error by reducing the long, bug-inducing manual merges.

Any number of people can check in their code, any no of times in a day, without waiting for others to complete their coding, wait till they finish their check-in and later check-in. So, CI removes dependency or removes the waiting time of others checks in.

Thus, team members need not have to wait for the other team members to finish their check-in and hence allows to work in parallel.

Every check-in just does not stop at getting collected at the version control, but immediately gets qualified through the build formation and automated testing. So, each check-in is validated at the root itself for further processing.

There is no chance to miss anyone’s code because everyone’s code is checked into the master copy with the time stamp and hence properly recorded.

The entire process of compiling, building and testing runs in few seconds and hence quite quicker and faster and saves a lot of time and hence helps to achieve the DevOps objective of delivering faster over a period of few hours.

Since the entire process of building and testing runs over a few seconds to minutes, the feedback on individuals’ code is very quick and we need not have to run around to find out whose code has broken the build or induced the defect, as with every check-in it gives the success or failure output indicating the area of failure if there is a failure.

So, this allows the developer to check in the small amount of code intermittently, maybe even a single line of code, to ensure that it is error-free and makes the developer to have confidence that their code is good and also does not break others code. So, this in total helps to improve the quality of the code.

Let us pause here and let us pick up the continuous delivery and continuous testing in the upcoming video tutorials.

PREV Tutorial | NEXT Tutorial