Agile Blog Sponsored By  Agile Sponsor    Agile Sponsor   



Continuous Integration... What's Involved

Written by  Sudheer Raju | 09 November 2010
E-mail PDF

Talk about integrating code to any developer and it seems to be the most painful activity of whole development lifecycle. We, the developer community tend to integrate our code once we are happy that all development is complete, tested and about to release the source to production....there you go loads of issues post integration due to either lack of complete knowledge on code being integrated or integrated code not tested properly and many others.




Continuous Integration is small pieces of effort to integrate source code at very regular intervals within a day by the development team with a view to avoid complexity of integration at the end, ensure good quality of code and reduce time taken to deliver it.


Source Repository

The main aspects of a source repository are

  • Define a well structured repository for your code
  • Use a source repository tool like Subversion or Perforce or any others
  • Ensure all the files are in repository than your local machines including libraries, IDE configs etc
  • Be clear on Single repository or Branching (Single Repository preferred always)

Before you go about setting up your source repository ensure you have defined a logical or organized structure for your source code.  You may want to put all your common code at single folder, user interaction code in one folder and likewise. There are many source repository tools in the market that can be used to store all your source code with necessary access permissions. Availability of open source tools makes life better than having nothing.

The biggest and common mistake that we all see is that team members trying to make changes on their local machines and not integrating with the main repository. Encourage all the team to put everything on the source repository so that issues like missing files, incorrect changes and others are prevented.

Often it is said that all changes have to be done on single repository, but in my whole experience i never came across a single company which did not feel the need to branch their code for one or the other reason. Although i would encourage making changes on a single repository as much as possible, have an alternate strategy to be ready to branch your code. Branching should be carefully planned with agreed strategy, branch naming conventions, checkin/checkout process, commenting formats, regular intervals to synchronize branch with changes in trunk and viceversa if possible. Branching does not add complexity if we stick to continuous synchronization with trunk and carefully planned.

Build Process

  • Key aspects of Build Process
  • Ensure all files are checked into repository
  • A build script is available or a build tool like Ant, Maven, MS Build
  • A sensible build time of 10 to 15 minutes is achieved
  • Build Automation
  • Testing is done automatically as part of Build Process

The key pre-requisite for anyone to start a build is to ensure the all the files, libraries or dependent source code is all checked into source repository for a compilation and building the build. As Martin Fowler ones has written, “everyone commits every change, every commit on the trunk should be built”. It is very handy to use build tools like Ant, Maven or MS Build and many others rather than relying to do a build manually. There is every need to ensure the build process does not take more than 10 to 15 minutes to ensure the developer community does not spend all their time ensuring a successful build.  Most projects does achieve this by using good tools available in the market.

It is a good practice to let automated build process test the build itself rather than any manual intervention. A good practice is to write unit tests using JUnits or any others and include them in your source to ensure they are built along with the source and the build is tested automatically and results published. All the tests pass indicates successful build.


  • Build test results are published
  • Latest build and build numbers are clearly communicated
  • Automated notification before and after the build process
  • Build failures analyzed for root causes and closed

A build process is considered good if there is a clear mechanism to communicate the start and end of build so the developer community can always take the latest changes into their local repository and test their own changes for any impact. Build results are communicated on a regular basis to ensure team are aware if a particular build has failed. Its often a good practice to identify the root causes of build failures and see if a review checklist is enriched to minimize failures for future.

Key Advantages of Continuous Integration

  • Reduce code complexity and create more modular code by continuous integration
  • Early identification of failures or broke code
  • Immediate testing of all changes rather than leaving it until the end
  • A stable build available at any given time

Disadvantages of Continuous Integration

  • Takes time accept and settle down the build process
  • Rich hardware might be required to achieve successful build process
  • Well designed test suite to test the build always required


Continuous Integration allows to delivery software quickly and with minimal chaos towards the end. It may a bit time consuming at the start to setup the process and align the organization to follow but this is absolutely necessary to ensure we de-risk our development cycle from chaos and waste of valuable time. Suggest to go through following book for more details......

Feel free to contact me on This e-mail address is being protected from spambots. You need JavaScript enabled to view it or This e-mail address is being protected from spambots. You need JavaScript enabled to view it if you need more information. Please do provide your valuable feedback and comments so i can keep this article updated at all times with our experiences.

Author: Sudheer Raju, IT Project Manager,  This e-mail address is being protected from spambots. You need JavaScript enabled to view it  

Sudheer Raju

Sudheer Raju

Founder of ToolsJournal, a technology journal on software tools and services. Sudheer has overall accountability for the webiste product development and is responsible for Sales and Marketing. With a flair to write, Sudheer himself writes for toolsjournal across all journal categories.

blog comments powered by Disqus