My current hobby, as said in a previous post is CI. I strongly beleive that having a CI in place for your development speed up, and secure your development process. SO, in order to convince or to help you to set up such framework, i’ll try to summarize and give the key point of such framework.

My current feeling, is that a CI framework is mainly maid of 3 major block, with 2 optionnal small one. We can wrote a book on the small one, but regarding to the big CI bloc, they are small in this context 🙂 .

This 3 blocks for me are :

Source code repository : this is the entry point of the whole story, the place where all the developper commit their code, the source from your application releases are build, the central point to get the history of your code writting skill history. In this family the most well known source code repository tools are : CVS / Subversion / Perforce …..

The build tool, often forgotten, allow you to transform you source code into a deployable library or an application. I emphasis this point, as often it is consider as a minor element of the CI, but i strongly believe that’s the hart. Indeed, well used, it’s allow you to build easily library, handle dependency among your library, allow you to easily standardize programming rules or tools to run among your libraries. The most common are Ant/Maven/Make/phing/…. At this point i will rise a little warning. In large/medium size company, your application is made of several block, some of them can use several programming language (SQL for your DB, Java/C/C++ for the backend/middle tiers, PHP/JavaScript for the front end, perl/sh for the scripting part, ….). So a big choice will be either to use the same tools for all the application block, or use a more specialized one for dedicated part. The choice is not easy to do, but one of the argument will be the IDE used by the human to wrote their code, and the integration of the build tool with this IDE.

The CI tool. For me this tools should only ensure the synchrnosition between the source repository and the build tools. Each time something change, at fix hour, when a tag is set on the code it should launch a build of the whole application. It should keep also an history of all the build, and the documentation/metrics produce by the build process (hudson, continuum, cruise control, …).

Now, the two optionnal part, ecause they are nice to have, but not mandatory to succeed in CI. The IDE, which is the entry point of the code. I will say that’s an optional part, as you can do CI without it, but i think to strongly benefit of the CI, of the instrumented build tool, the standardization of the DEV, a good IDE with some instrumentisation is a huge benefit (Eclipse, netbeans, ..) .

Deployment and configuration management tools : definitively forgotten in most of the framework, the deployment and the configuration of your application is a key issue. You application is not only WebService or an simple programme. It’s composed of a bunch of library jar, so, rpm, a bunch of application (scripts, cron, monitoring, admin, ….), and requier a set of configuration to allow each part of your application to interact together, or to configure your OS. In a perfect world, the same tools is used in CI, QA, and production in order to validate deployment and automate it, as soon as possible.