Continuous Integration: A Good Configuration Management Practice

Published on
7,939 Points
Last Modified:
Integration of the code changes made by multiple developers from multiple locations to main code line is continuously a problem area, as any code change may stop successful compilation of the code and may introduce multiple defects. To overcome this challenge a common practice is used called Continuous Integration (CI).

CI is now a common practice used in software development; mainly used when multiple teams are working on the same code lines and contributing to code changes. This helps in making sure that after every code change the changes are valid, and are not breaking any part of the code. This is verified by a two step process. 1st is New Build Creation after every code change followed by the 2nd step of Automated Unit Test Cases Execution. The 1st step makes sure that all the latest code is picked from the code repository and code is able to compile successfully, and the 2nd step does testing by running unit test cases automatically.

Another step that can be part of this process, which makes it a more sophisticated process, is automatic deployment of the build followed by execution of the Automated Test Cases.  This deployment is for UI verification and distribution of overall status of the Build quality to all stake holders after each new code change.   This practice helps in detection of the integration problems immediately after the check-in, and always keeps one successful build if needed, so that if there is a build failure by any of the check-in, you will be ready with the one previous to the failed build.

Continuous Integration with a Source Code Repository system like Microsoft’s Visual Studio Team System (VSTS) makes it more powerful.  Use of this system helps in pinpointing a specific change set that caused the build Failure and helps with many configuration settings for Build Creation.

There are multiple benefits of this practice as it gives comfort to the configuration management team.  But from a developers point of view it makes the whole process slow.  After every check-in, a whole build is created and deployed with all Unit Tests successful.  If the product is huge, which can take a 1-2 hours build process after the check-in, the next check-in is stopped until the first check-in build is completed successfully.  This is because no check-in should be made before a previous build is successfully completed.  But, there are ways to handle such situations, as proposed by VSTS, to configure multiple Build Servers and planning work of multiple teams on a specific Build server.

Featured Post

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

Join & Write a Comment

With the power of JIRA, there's an unlimited number of ways you can customize it, use it and benefit from it. With that in mind, there's bound to be things that I wasn't able to cover in this course. With this summary we'll look at some places to go…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month