‍‍‍‍Continuous integration‍‍‍‍ (CI) is the process of integrating work frequently in a software development process allowing developers to detect and resolve errors and integration faults quickly (Fowler, 2006).

Introduction



In the early 1990s, Kent Beck was recruited by Chrysler to help rescue a highly visible but failing project, the C3 payroll system. Addressing the issues led to the beginning of Extreme Programming (XP) which he successfully implemented and resulted in saving a disaster ridden project, hence, making this methodology popular, especially within the software community. There are a number of practices embedded within the XP process with CI being one.


Definition



CI in Agile Software Development may be viewed as having many layers, each building upon the previous layer. At its simplest, each code change performed by a programmer (or pair of programmers) is committed to the source control repository. A separate system, known as a CI Server, monitors for these commits and upon notification of this happening, extracts the latest version of the code and attempts to build it. If the code fails to build then this is recorded and the programming team are notified of the failure. An important aspect of Agile Software Development is to investigate why the build is broken rather than who broke it - which gave rise to the term 'Its Chet's Fault' during the early days of Extreme Programming (Jefferies, 2004).

This practice can be directly related to the Lean Development principles such as ‘Eliminate waste’, ‘Deliver fast’ and ‘Build Quality In’ as CI helps to reduce time on finding bugs, increase pace of delivering features through automated process and check all the time that the whole code is still working properly. Besides Extreme Programming principles, for example 'Improvement' and ‘flow’, are also connected with this practice because continual automatic processes can enable to deliver working code during whole life-cycle through deploying frequently smaller increments.

According to Forrester Research (2010) the presented aspect of Agile methodology, CI and build, is common practice for the Agile projects. In addition, IT departments are not the only places where this technique can be applied, based on survey technology companies are also using CI in their processes.


Continuous integration process
Continuous integration process
CI can be compared with the process of making films by continuously adding new frames and checking the movie every time from the start to see that the whole film is still making sense and does not contain any types of errors.

In more technically aware agile teams, upon a successful build the CI server may also run the Unit Tests developed during the Test Driven Development stage, along with deploying to a test architecture for further acceptance testing. Though some teams prefer the manual approach to CI, Cohn (2010) strongly recommends against this, advising the use of automated software such as Cruise Control (the most popular amongst known CI software). With Cruise Control facilitates building of product, test run and sends automated notifications of build results to the entire team or a developer who wrote a wrong code. It is also known to interface with feedback devices such as lava lamps, ambient orbs, spare monitors, LED displays, and more (Cohn, 2010).

Requirements




Schiel, J. (2010) claims that in order to apply CI into development process it is essential to consider following requirements:
  1. The system must be able to start a build automatically;
  2. The system must be able to save the results of tests automatically for a specified period of time and allow to review reports later;
  3. If the build fails, the system must be able to notify someone regarding arisen issues.

Advantages



Lindvall et al. (2004) claims that the CI positively influences on the projects, below the main advantages derived from introducing a CI server are shown:

  • Immediate Feedback - during more traditional development methods, integration is left until near the end of the project which results in bugs and integration issues being identified late in the process. This stage reports the largest number of bugs within the system (Hunt, 2007). These delays are often costly whilst investigations proceed to resolve the issues (Jefferies, 2010). With CI the development team are immediately made aware of any issues whilst the latest code changes are still fresh in their minds.
  • Automated 'Live' Deployment - building upon the functionality provided to deploy to a test infrastructure, this same process could be utilised to deploy to a live infrastructure at little or no additional cost. Consideration should be given to automated roll-back in case bugs or unwanted functionality arises. (Fowler, 2006)
  • The process for building is automated. In more traditional development methodologies the building and integrating was normally left to 1 or 2 individuals. With the method being automated, anyone can schedule a build and the process is already documented (via the scripts).
  • The frequency of CI ensures the latest "version" build is what is being tested and demonstrated to the customer.
  • Developers receive continuous feedback from client on the quality and operability of the code they are producing.
  • Creation of standardised and less complex code.


Disadvantages



It is generally accepted that the benefits gained from CI far outweigh the issues encountered (Fowler, 2006). However it is worth mentioning the following issues that may arise:

  • Initial Set-up Cost: Costs related to the physical architecture required for the CI Server and Source Control repository.
  • Acceptance: Fowler (2006) described the difficulties in gaining acceptance for CI and a disbelief in its effectiveness when he described the practice to novices.
  • Slow Build Times: Due to the continuous builds and the benefits being realised by immediate feedback its important to keep the building of source efficient. According to Shore (2008) it is important to keep the build time to within 10 minutes, especially for new products.

References


Cobb, C. (2011) Making Sense of Agile Project Management: Balancing Control and Agility. John Wiley & Sons, 2011
Cohn, M. (2010) Succeeding with Agile: Softwware Development Using Scrum. Pearson Education, 2010
Forrester Research (2010) Agile Development: Mainstream Adoption Has Changed Agility. Available at http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2 [Accessed: 23 February, 2012].
Fowler, M (2006), Refactoring : Improving the Design of Existing Code, Addison Welsey
Jefferies, R. (2004) Extreme Programming Adventures in C#. Microsoft Press, 2004
Jefferies, R. (2010) What is Extreme Programming? Available at: http://xprogramming.com/what-is-extreme-programming/ [Accessed 23rd Feb 2012]
Hunt, A. and Thomas, D. (2007) The Pragmatic Programmer: from Journeyman to Master. Addison Wesley, 2007
Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., May, J., Kahkonen, T. (2004) ‘Agile Software Development in Large Organizations’. Journal Computer. 37(12) pp.26-34
Schiel, J. (2010) Enterprise-Scale Agile Software Development. Boca Raton: Taylor and Francis Group, LLC
Shore, J. (2008) The Art of Agile Development. Sebastopol: O'Reilly Media, Inc.

Continuous integration can be compared with the process of making films by continuously adding new frames and checking the movie every time from the start to see that the whole film is still making sense and does not contain any types of errors.