The Why and How of Continuous Integration

By Pankaj Srivastava

Continuous Integration is a development engineering practice that integrates code after each check-in done by developers into a shared repository and helps to find out code errors & code breaks early before it hampers the development process of other developers.

It is a myth that Continuous Integration is an agile methodology practice. A development engineering practice is not dependent on the software development methodology being followed. It can be implemented in any software development methodology.

Why is Continuous Integration required?

Software development project is bound on a strict schedule by the SOW/contract/MSA. If the project violates the schedule, both vendor and client have to face financial and reputation damage. A delay in schedule may lead to loss of potential revenue for the client as a competitor may market the targeted features first and capture the potential market. This ends up impacting the client’s reputation as well. The vendor, on the other hand, has to pay financial penalties as mentioned in the SOW/contract/MSA. Delay in delivery would also impact the vendor’s reputation and may lead to financial damage during future biddings.

Demanding projects creates pressure on the developers. Hence, during the latter stages of software development, developers start opening developers “magic tool box” which includes “Say it’s done”, copy code from Google without reading it, overtime, no exception handling, hard coding, inappropriate unit testing etc.

Sometimes developers end up missing the complete check-in (all the files) which leads to build errors. In worst case scenarios, developers check-in incomplete code without build without running the code once or without running all the unit and integration tests. The oversight leads to functional errors and code breakage.

Continuous Integration is a precaution against the aforementioned build errors/code breakage for the historic code.

Achieving Continuous Integration

At IGT, we used the Microsoft Team Foundation Server (TFS) as shared repository and Microsoft Team Foundation build script for build automation. The team foundation server delivers source control, work item tracking, version control, test case management, build automation, a team project portal Web site, reporting, and project management capabilities.

  1. Handling post check-in build errors: Initially, the objective was to avoid post check-in build errors. To achieve this, a TFS build script was written which would run after each check-in. The script was written in such a way that it would send email to all concerned stakeholders following each individual check-in. As soon as any post check-in build failed, all concerned stakeholders including the concerned developer were informed via automated email. The developer was required to fix the fault as soon as the build failed email was received. This practice also ensured that the “magic tool box” was used less since any error would lead to the developer’s name being flashed to all the stakeholders in red.
  2. Avoiding historic code breakage: Automated unit test for all historic and new code were written using TDD. The Unit tests were created in Visual Studio using the Visual Studio Unit Testing Framework. Going forward, a running unit test was added to the TFS build script so that whenever any existing functionality was broken by new code, all concerned stakeholders would be informed about the code breakage and the particular functionality that was broken. The Unit tests execution in TFS build script were done using MSTest.
  3. Gated check-in: Until the post check-in build was corrected, the work of other developers was getting hampered. Hence, it was imperative that check-in should not succeed in case of a failed build. The implementation of a Gated check-in ensured that the code was not checked-in in case of any error.
  4. Fxcop tool:FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. The Fxcop rules were implemented in TFS build script to find any possible design, localization, performance, and security flaw. It added an extra review layer to the code.

 Tools for implementing Continuous Integration:

Many tools are available in market to implement Continuous Integration. These tools may be classified into open source and commercial tools. Open source tools include Hudson, Jenkins and CruiseControl while the Commercial Tools include ThoughtWorks’ Go, Urbancode’s Anthill Pro, Jetbrains’ Team City and Microsoft’s Team Foundation Server.

(This article has been published in www.scrumalliance.org )

___________________________________________________________________

About the Author

PankajSrivastavaPankaj has 12+ years of experience in Microsoft technologies. A certified Project Management Professional (PMP) from PMI and Certified ScrumMaster from ScrumAlliance, Pankaj has wide experience in Agile (Scrum) implementation while working with Customer and in Traditional Software Development Models. Pankaj is also a member of the Scrum Alliance community. Pankaj can be reached at mktg@igt.in

Leave a Reply

Your email address will not be published. Required fields are marked *