Continuous Integration for Junior Software Engineers

by Harshit Kandhway, Nishant Madan, Preeti Theraja, and Sakshi Grover

In our first week at Xebia, we were introduced to the practice of Continuous Integration. Continuous Integration is a development practice that requires developers to integrate code into a shared repository several times a day. Each time the code is checked-in, it is verified by an automated build, allowing teams to detect problems early. With Continuous Integration, we can test and verify all the modifications during the development cycle and implement it throughout the project.

As shown in the above picture, CI is a continuous process that provide quick feedback to the developers.

We are junior engineers(1–3 years experience) who have joined Xebia in last one month.We didn’t followed CI practice in our previous organisations. Since we had not used this practice we were under the impression that integration is a long and gruesome process. Every software project needs to go through this. It is reality of the life.

Once we learnt about CI, we realised that if we adopt this practice during software development lifecycle then integration effort will be minimal.

Below are the four reasons we think why one should use continuous integration.

Reason 1: Reduces integration problems and improves collaboration

Software development is a social activity where in multiple individuals work together to build novel things. As multiple developers work on different features it becomes critical to continuously integrate the work. At any moment, we should know if our stuff is in working condition. If we don’t integrate our work early, then it will be a difficult job for us to figure out the root cause of our problem.

Continuous integration promotes fail fast philosophy. We discover Integration integration issues sooner. This reduces stress of developers improving the collaboration within the team.

Reason 2: No more works on my machine reasons

Continuous Integration automatically builds the code before the changes are merged removing developer’s dependency on machine specific variables. For instance, if the developer wants to build a maven project then CI compiles the code irrespective of the environment that is setup on the developer’s machine. So, while deploying the project developer need not take local machine’s variables into consideration as CI does this task at its own.

Reason 3: Rapid Feedback

Continuous Integrations cannot fix bugs for us but it can help us find bugs. These are usually found when have flaky tests. If the code doesn’t build successfully, CI can easily detect the errors due to which compilation/build failed. CI is an angel watching developer back providing quick feedback. It tells us about the health of our project. If the build is green, we know things are working fine.

Reason 4: Gateway drug to Continuous Delivery

Another thing that we learnt at Xebia is the concept of continuous delivery. Continuous delivery is the ability of a team to deploy features, bug defects, and configuration changes into production environment in an automated manner. Continuous integration is the starting point. Continuous Delivery sits on the strong shoulders of Continuous Integration. To do Continuous Delivery well, we need Continuous Integration.

One of our seniors shared with us to the below mentioned quote by David Farley from his book on Continuous Delivery that also makes the similar point.

The deployment pipeline has its foundations in the process of continuous integration and is in essence the principle of continuous integration taken to its logical conclusion. CI is the starting point. You can’t do DevOps or build automated deployment pipelines if you don’t have CI server setup.

At minimum CI server, should continuously build code when changes are merged to master and pull request are raised. It should run all the tests and if any of the test fails build should fail.Good practices build on top of each other just like good habits. If an organization wants to ride the DevOps bandwagon then CI is the starting point.

The above are few of the reasons we think we should use Continuous Integration.