Get certified - Transform your world of work today


Continuous Integration

Why, how, and tools used

13 July 2015

Pankaj Srivastava
Interglobe Technologies

Continuous integration is a development engineering practice that integrates code after each check-in done by developers, places it into a shared repository, and helps to find code errors and code breaks early, before they hamper the development process of other developers.

It is a myth that continuous integration is only an Agile practice. A development engineering practice is not dependent on the software development framework being followed. It can be implemented in any software development method.

Why is continuous integration required?

Software development projects are bound to a strict schedule by SOW, contracts, and MSAs. If the project violates the schedule, both vendor and seller face damage, to both finances and reputation. Schedule delay may lead to slippage of potential revenue, as a competitor may market the targeted features and capture the market first, which impacts the seller's reputation. On the other hand, the vendor has to pay financial penalties per the contract. Delivery delay may impact the vendor's reputation in the market, which will cause financial damage during future bidding.

Demanding projects also create pressure on developers: During later stages of software development, developers may start opening their "magic toolbox," 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 miss the complete check-in (all the files), which leads to build errors. In worst-case scenarios, developers check in incomplete code without build or without running it once, or without running all unit and integration tests, which leads to functional errors and code breakage even in areas that were running fine before. Continuous integration is a precaution against build errors and code breakage for historic code.

How we achieved it

We used Microsoft Team Foundation Server (TFS) as shared repository and Microsoft Team Foundation build script for build automation.
  1. To handle post check-in build errors: Initially we started to avoid post check-in build errors. In order to achieve this we wrote a TFS build script that runs after each check-in. We wrote them in such a way that they sent an email to all concerned stakeholders after each individual check-in. As soon as the post check-in build failed, all concerned stakeholders were informed via automated email, including the developer whose check-in failed the build. The developer would then fix at as soon as the build failed and the email was received. However, this caused the developer to fear that his name would be flashed in red to all the stakeholders.
  2. Avoid historic code breakage: We started writing an automated unit test for all historic and new code using TDD. Unit tests were created in Visual Studio using the Visual Studio Unit Testing Framework. Later we added running unit tests to our TFS build script so that whenever existing functionality was broken by new code, all concerned stakeholders would be informed about the code breakage and the particular functionality that was broken by the new check-in. Unit test execution in TFS build script were done using MSTest.
  3. Gated check-in: Still, the work of other developers was hampered until the post check-in build was corrected. So we thought check-in should not succeed in case of a failed build. Implementing gated check-in helped with this problem when there were any errors.
  4. Fxcop tool: FxCop is an application that analyzes Microsoft .Net assembly's (DLL and EXE files) and reports information about them, including design flaws, localization, performance issues, and security improvements. We implemented Fxcop rules in TFS build script to find any possible design, localization, performance, and security flaws. It added an extra code review layer to code.

Tools for implementing continuous integration

Many tools are available in the market to implement continuous integration. They can be classified into open source and commercial tools. Open source tools include Jenkins, CruiseControl, and Hudson. Commercial Tools include ThoughtWorks' Go, Jetbrains' Team City, Urbancode's Anthill Pro, and Microsoft's Team Foundation Server.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.5 (4 ratings)


Naveen Kumar Singh, CSP,CSD,CSM,CSPO,REP, 7/13/2015 1:23:58 AM
Pankaj - Well written. CI, TDD or BDD etc has nothing to do with Scrum because these are good engineering practices that can be adopted anywhere. But these practices deliver more value when get combined with scrum.
Pankaj Srivastava, CSP,CSM, 7/13/2015 10:38:08 PM
Thank you Neveen. Yes you are right. Engineering practices have nothing to do with Agile. However, they are always deliver product with good quality.
Shalu Tyagi, CSP,CSM,CSPO, 9/10/2015 6:05:13 AM
Hi Pankaj,

Congratulations !!

Very informative article indeed.I find this practical implementation piece through TFS quite interesting.

Good Job !
Pooja Ummat, CSM, 10/14/2015 3:44:56 AM
Congrats Pankaj !! Great article

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up