Sunday 9 June 2019

Continuous Integration In DevOps

What is Continuous Integration in DevOps?

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.

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.

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.

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.


1 comment:

Topics

ADFS (1) ADO .Net (1) Ajax (1) Angular (43) Angular Js (15) ASP .Net (14) Authentication (4) Azure (3) Breeze.js (1) C# (47) CD (1) CI (2) CloudComputing (2) Coding (7) CQRS (1) CSS (2) Design_Pattern (6) DevOps (4) DI (3) Dotnet (8) DotnetCore (16) Entity Framework (2) ExpressJS (4) Html (4) IIS (1) Javascript (17) Jquery (8) Lamda (3) Linq (11) microservice (3) Mongodb (1) MVC (46) NodeJS (8) React (11) SDLC (1) Sql Server (32) SSIS (3) SSO (1) TypeScript (1) UI (1) UnitTest (1) WCF (14) Web Api (15) Web Service (1) XMl (1)

Dotnet Guru Archives