The term “continuous integration” is getting a bit of attention these days. It refers to the process of integrating often (or immediately) to reduce integration effort, complexity, and pain and to make changes more readily available to others. While the term “continuous” is catchy, it is not accurate in what the concept implies. In context to integration, the term “continuous” implies a process without interruption.
In software development, while changes are not continuous, what is really meant is to integrate often or frequently. Thought should be applied to determine when and how frequent integrations should occur, to re-work the development process to support frequent integration, and to setup an infrastructure that can support this approach. This paper provides some useful guidance in establishing an environment where frequent (or continuous) integration may be possible.
Understanding the Approach
In general, continuous integration is the process when code is checked in and is immediately built in the integration stream to see if it can build with existing code. If the build is successful, then an automated set of tests are run to validate the changes. Once the build and test are successfully completed, the results are made available to the rest of the developers. The premise is that when you continuously integrate, you can continually encounter and overcome small manageable integration issues during development avoiding large time-consuming integration issues.
Consideration should be given to whether a continuous integration approach is right for you. Most projects these days operate in the classical integration approach where changes are not frequently made, the changes may be quite large and include changes in numerous files, and other developers do not have to use these changes until they are ready. The continuous integration approach applies the changes to the public very frequently, the changes are typically small and precise (change only what exactly needs to be changed) where one or few files are changed, and the developers must be ready to accept the changes after they have been successfully built and tested.
Effectively, the continuous integration approach is a cultural shift for many developers who, following the classical approach model, like to work securely in their static workspace and not have to consider other changes until they are ready for them. The issue with the classic is that the changes from developers are not applied very frequently, therefore integration (e.g., merging) may become a significant and often painful effort. The continuous integration approach reduces the significant integration effort, but requires a different development methodology whereby developers are working on smaller change requests and change sets which require less time to complete. With all of this in mind, how would a group change from the classical approach to the continuous integration approach?
In order to start applying the continuous integration approach, consideration should be given to what needs to be in place to make this happen. First, there must be a development methodology in place to support this new concept. Second, there must an infrastructure in place that can support the continuous integration approach.
When considering the continuous integration approach, give thought to the development methodology. Continuous integration is much more effective when the work is chunked into smaller task. The requirements should be precisely written to represent small changes. The software should be developed in small increments or iterations. Testing needs to be integrated into this process.
Other Agile related methodologies include Scrum, DSDM (Dynamic System Development Method), RUP (Rational Unified Process), and RAD (Rapid Application Development).
The next step is to take the methodology selected and establish a development process. An example may