Continuous Integration - why? and how?
Thursday, August 20, 2009 by Sorin Serban

I was talking the other day with some colleagues of mine about the hurdles that they need to overcome each week in the development, and I could not help thinking about how much the software development landscape has changed lately and how we need to adapt.

In the  previous years (read more than 2 years ago)  one third of the development time was spent on writing exhaustive specifications which then went through intensive reviews, and then spend months before something was released; in the last years the focus was changed. Nowadays the specs are sketches at most, and releases are at least twice a month in order to get rapid feedback from the customer. This is fair in my opinion and allows for a more focused product and even if some aspects lack quality (because of the higher development speed) many others are better that their old-style counterparts.

The big question is though: how can we developers adapt to the new world? Obviously there are a lot of articles analyzing this and offering advice and solutions, but I will try to focus on a series of tools and techniques that can better our life.

What I am talking about is Continuous Integration. Continuous integration is an old concept which expresses the process in which all developers in a team, distributed or not, have to integrate their source code into the repository and validate the code base.  Of course this is something we all do so where is the "newness" factor. We'll start by stating the obvious process:

  1. Developer makes the code changes according to the specifications
  2. Code is committed to the repository
  3. A build is done on a testing environment with the new codebase
  4. A tester validates the new product
  5. If there are bugs, they are communicated to the developer and the process 1-4 is repeated until no bugs are found
  6. A kit is created for deployment on an acceptance environment
  7. The product is deployed in acceptance
  8. If the product passes acceptance testing it is then deployed in the production environment.

The process might differ from case to case but what is important to note is the lengthy process and the amount of human interaction in it. This is in the end a big hole where a lot of hours and money are poured. What should be done is automate the process by cleverly choosing tools and techniques.

The tools (.Net perspective):

  • Cruise Control .Net (alternative Team Foundation Server)
  • A repository, TFS  or SVN or others
  • NAnt - build tool
  • WatiN - for testing web applications (alternatives: Telerik Web UI Testing Framework, Selenium, etc)
  • patience and inventivity - these are prerequisites actually :)

Now by using the tools above, the process looks a little bit different

  1. Developer makes the code changes according to the specifications
  2. Code is committed to the repository
  3. CC.Net senses the codebase has changed and commands NAnt scripts to make the build.
  4. If the build succeeds it is deployed using NAnt to the testing environment.
  5. NUnit tests are initiated on the new build
  6. If the unit tests pass, the WatiN tests are executed (if the application has a web interface)
  7. If the WatiN tests pass, the build is deployed on the acceptance test where functional testers do their magic
  8. After the build is validated in acceptance, the build is deployed on the production environment.

Ok, the scenario is maybe too complete as in real life one might not deploy at each code commit also on acceptance or production; WatiN tests might not be executed all the time, etc. It's an equation of time, resources and paranoia and every team has to find a ballance. What is important, is that 5 minutes after committing the code, a developer has a proper indication that not only the build is ok, but all the functionality tested by NUnit and WatiN are not broken. Also, using NAnt builds, time consuming tasks like xcopy, creating directory structures, registering com's and other manual tasks, are done in mere seconds and the developer can focus on really important things.

 Try it yourself, even though it might take a while to setup everything, the end result is a little wonder that makes you finally free to just develop...

Usefull links:


0 comments
Filed under: Agile, CC.Net, CI, CSharp, DotNet, NAnt, NUnit, testing, WatiN, .NET
Comments
Blog post currently doesn't have any comments.
Leave comment





 Security code
 
ISDC ROMANIA
AVRAM-IANCU 506-508
407280 FLORESTI
CLUJ-NAPOCA
T / +40 364 403900
 
 
ISDC THE NETHERLANDS
ISDC THE NETHERLANDS
LAAPERSVELD 43
12 13 VB HILVERSUM
T / +31 35 623 80 15