What is Continuous Integration?

19 Jul

Continuous Integration is a software development practice. This practice and name firstly pronounced by Martin Fowler and Kent Beck in 1999. The idea behind this practice is integrating the code that is checked in by developers frequently.

Picture this scenario; you have a team of developers and every developer makes checkins their work. All of the developers try to build the changes they made successfully in their own machines. But every developer makes checkins and these checkins must be integrated and you need to know that all checkins can work in the whole system successfully. I know some companies dedicate some people only for this job -making integrations manually-. This is not a good solution.

The solution is automation! Continuous Integration (CI) automates this process.

If you want to some automation, you need to implement basic steps at the below;

  • getting latest of source code from source control repository
  • compiling source code
  • deploy/publish/package the output.

Actually, this 3 steps is not the steps of the Continuous Integration, these step can be named as “Continuous Build”.

If you want to implement the continuous integration process successfully, you need to add these steps too: (this assumes that you write tests)

  • get the latest of test projects from source control repository
  • build the test projects
  • runs the test against the actual project.

Building process must be fast because time delay of feedback to developers who just checked in is important to fix the problem.

Making checkin at one time a day is a good practice to follow the changes and detecting the causes of the problems when they occur.

A developer must get the latest version of the source code from the main repository,merge and build his/her changes before making checkin. This practice provides to developer to be ensure that his/her checkin builds successfully.

Picture this scenario, DevA and DevB get the latest version of the main repository when they came to the office at the morning (this is a good practice). DevA makes some changes on a portion of the project, built the project locally and makes checkin his own changes before the lunch. (Continuous Integration system successfully builds the project)

DevB works all day and completes his work, builds the project locally and makes checkin. But changes of DevA a breaks the changes of DevB. Continuous Integration system fails, can’t build. Suddenly everyone ask “Who broke the build?” And DevB starts to turn red. :)

Because of that geting latest version of the repository before checking in is a good practice.

If you want to setup your CI server and start to use this automation system, there are several tools for CI. You can use Go, Cruise Control.NET, TeamCity, Hudson (it is from java world but it can build msbuild files)

You can read Martin Fowler’s very detailed Continuous Integration article from this page.

P.S. : Team Foundation Server 2010 Build System comes with a new feature named “Gated Checkin”. This feature makes developer life easier because this feature invalidates the requirement of the getting latest version before checkin rule. (I will write about this later)

Comment Form