Agile 102: Continuous Integration Explained

One of the points in What is Continuous Integration (CI)? was the importance of having reliable automated build scripts and executing them often. CI can be seen as a natural extension of the Automated Builds practice since in most cases it relies on the presence of a set of ABS. A well-designed CI system encapsulates other sub-practices such as Continuous Builds, Continuous Database Integration, Continuous Unit Testing, Continuous Deployment, Continuous Functional Testing, Continuous Notifications, and Continuous Reporting. All of these are designed to shorten the time between the problem discovery and the problem solution. Agile teams can rely not only on the time-saving nature of automated asynchronous builds, but also on the timely and accurate feedback as a result of this type of CI.

Continuous Integration (CI) is an umbrella practice enclosing a sequence of logically related steps. Depending on the CI configuration, when one of the steps fails the CI server may choose to continue with the remaining steps or suspend any further operation until the failing step is fixed.

The typical CI system starts with the compilation and packaging of the application. Any problems at this stage will usually fail the CI cycle and the system will notify the submitter of the entire team of the failure. Once the problems are fixed the CI server will recompile and mode on to executing DDL and/or DML scripts as part of the database integration. This will ensure that the database will be up to date for the unit and functional tests that will follow. Assuming there are automated unit tests, the system will make sure to create test data and execute the unit tests in the suite. Depending on the server configuration unit test failures may or may not fail the CI cycle. In the next two steps the CI server will package and deploy the application. After all functional tests successfully pass, the CI server will label the code with an automatically generated label, it will notify a list of recipients and will generate a report of the integration cycle.

An Agile team can benefit from such a system in multiple ways. For one, the system can provide an immediate feedback to all parties shortly after a problem is discovered. Secondly, it can create valuable deployment artifacts and reports targeting different audiences within the Agile team.

One variation of the above diagram is if the CI server is configured to run code inspection tools as part of the CI cycle. Static analysis tools run from the CI server can generate reports on code metrics such as lines of code, test coverage, cyclomatic complexity, package coupling and dependencies, and can provide important data points for the entire team as to where the system stands in terms of code quality and architectural integrity.

A second variation of the diagram can happen when successful completion of the functional tests triggers a second deployment to another machine. Since the CI server knows it is a good build, this time it deploys to a user acceptance machine, targeting the customer directly. The advantage of redundant deploys is that semi-independent teams such the User Experience (UE) have a machine that always runs the latest good build.

Reference: This blog entry is derived from author’s own real-world experiences building CI systems and industry best practices. One of the leading sources for CI best practices is Addison-Wesley’s recently published Continuous Integration, a Martin Fowler Signature Series title, authored by Paul M. Duvall with Steve Matyas and Andy Glover.