CridManager 2.0 - Continuous Integration

• Article about CI
• CruiseControl Overview

Continuous integration is one of the legs of the eXtreme Programming (XP) or Agile methodology.

With the test-code-refactor-test methodology you solve some typical problems we all found when developing a new programm/system. But this only works well if you are a single developer.

But when you are working in a team, you have new problems to solve. Typical of this is:

• Version Control: First of all, you need a secure place where all versiones of your code must be stored. This is even needed when you work alone, in order to get back to a previous version in case you made a mistake in the code. But it is more important to have controlled the code. In this way, if you release a new version of the program and 2 moths later you get informed of a new bug, you can allways get back to the same original code to try to reproduce the problem. In other way this would be impossible. In CridManager 2.0 we use subversion as our version control platform.

• Developers changing the same part of the code: If more than one developer is modifying the same module, there can be conflicts between both codes that can be difficult to solve. And even if there is no conflict directly in the code, there could be some changes that affect one each other. It is needed to merge the code of the different developers, and test it all together (using unit testing)

• Out of aligment between the different modules of the program: 2 developers coding 2 different modules that have a common interface can work separately (even with their own unit tests) but then we need to test the end-to-end between the 2 modules. We need other tests (black box tests) to check that.

• Isolation of the code: When you are coding a program, beyond the code, you have dependencies (jar, libraries, etc) that make your tests to work in your own environment but, will it work in a different environment? Usually we make a program to put in service in a production plant or to share with others in very complex different environments. We need an isolated environment where we test the program to be sure there are no local dependencies of the code from our own.

• Reliability of the builds: If there is no control over those 4 points, our builds will never be reliable.

One of the most popular platforms for Continuous Integration is cruisecontrol. This platform is developed in Java, and give to you the following features:

• Provides an isolated environment for unit tests and end-to-end tests. It is able to detect changes in our Version Control System (ClearCase, subversion, CVS, ...). Then it will clean the project directory and will start a build loop from the beginning. Download the code->Compile->Execute Tests

• Reporting: IT has its own web server with all the reports of different builds, with the results of compiling and testing. It will send an email to the team members with the results. It is able to inform about which test has failed or if the result is OK.

With these 2 features you can afford the risks of the team coding. Developers will make the changes, compile and make the unit tests in their local environment. After that they upload the code to the VCS and from now on CruiseControl will detect the changes, compile and run the tests in the isolated environment. It can detect for example if a change I have made in my code is affectting other modules using the unit tests of both modules. Or if I have not uploaded a new library to the VCS that I have locally, CruiseControl will not be able to compile the code, giving the result in the report.

In such another way we would lose a lot of time trying to solve problems due to those 4 points.