Setting up a Continuous Integration Server is one of the firsts steps I perform when starting a new project, it’s become a development practice that I can’t live without. If you are working in a team with even a few team members the benefits are simply immense. In this series of posts I will explore the basics of CI and then move onto some real world examples of using CI. I hope to cover areas such as automated testing, enforcing source code formatting, documentation generation, database change script generation, installation package creation and automated deployment in relation to CI.

In its simplest form CI is an automated way of frequently checking the state (in terms of quality) of a software project. In order for the state of the project as a whole to be checked, the work of each team member needs to be assessed as an integrated part of the project. This inherently means that frequent integration of each individual’s tasks is essential to the process. While many teams unaccustomed to CI initially feel this is not possible, experience has shown that it is not just possible but that integration concerns very quickly become “non-events” in practice, with team members usually integrating with no ill effect at least once a day.

CI however should not stop at just being a source code integration tool, when utilised to its fullest a CI server can provide a confidence in your product from development to production deployment that cannot be rivalled by manual processes.

There are a myriad of CI servers available and I will discuss some of them in detail in later posts however the basics stay the same. Most offer a web front-end to manage and control the build process, modules to manage the server and per project configuration as well as security and access control. The basic operation of a CI server is to watch a versioned source code repository for changes, usually at a set time interval, and if changes are detected to execute the tasks associated with the project. The task execution engines are generally very configurable and have the ability to check in/out source code, build documentation, label versions, compile source code, run tests and deploy projects.

As a rule I don’t suggest using the CI servers built-in capabilities to execute a source code compilation task but rather using a dedicated build automation platform like MSBuild or NAnt which most CI servers will also support. It is of utmost importance that a source code build is self sufficient and can be compiled on any machine the code based is checked-out to in exactly the same manner as on the CI server without the need for environmental dependencies. Using a build automation platform also ensures that if you do change your CI server the source code build will still run as expected.

The build automation platform can be used to automate a wide variety of quality control and administrative tasks as part of the CI process:

Auto generation of change scripts for deployment to a production environment (Redgate SQL Tools)

Where applicable installation packages can automatically be created

For advanced scenarios an automated deployment procedure can be created and possibly result in Continuous Deployment

CI is a simple process and can be evolved over time, even the first step of having the server check-out and build your projects source code from version control a few times a day will provide immediate benefits and provide a platform for spending more time on better software practices.