Continuous Integration

Continuous Integration refers to the practice of continuously applying quality assurance to software, applying small amounts of effort frequently in contrast to traditional practices of applying a large amount of integration and quality assurance effort at the end of a project, phase or timebox.

Continuous Integration involves building the product repeatedly, as often as after every change in an Integration Stream or woskspace performing some level of quality assurance to establish a basic level of Done such as “Unit Tested”.

Continuous Integration is, as the name suggests, a very frequent activity and so normally relies on some level of automation in terms of both build and quality assurance. Automated unit tests typically rely on the software build being built for compiling technologies although static analysis and runtime automation are available for some interpreted languages, notably web languages such as JavaScript. In significant software projects, builds can potentially take quite a long time, especially if resolving dependencies from a binary repository.

It may not always be practical for every developer to do a resource intensive build and unit test run in their own development environment, sometimes doing a team build and unit-test run is more appropriate in a Continuous Integration Environment. Doing a team build and running automated quality control activities whenever there’s a change to the code is Continuous Integration.

To implement the Continuous Integration practice there needs to be a team based view of the software source assets in an Integration Stream, typically provided by a version control system, an automated build and automated tests, or other quality control functions. There is some value in just doing an automated build whenever the code changes as it ensures that the code at least compiles, but the real value comes from adding quality control to the build process.

Some of the advantages of Continuous Integration include:

  • When a unit/test or build fails the team can revert to the previous bug free state without wasting time debugging, simply re-implementing a small change
  • Developers detect and fix integration problems continuously
  • Early warning of broken/incompatible code or versions
  • Immediate unit testing of all changes
  • Constant availability of the “current” and “last good” build for testing, demonstration or promotion to release and live environments

Some minor percieved disadvantages include:

  • Initial set up time to configure build service and build
  • Good coverage and well-designed unit tests are required to achieve quality benefits

However, these are not real disadvantages since any amount of automated integration and quality activity pays for itself many times over. Complete coverage is not required, and indeed is a practically unobtainable goal in anything non-trivial. If reality you can’t afford not setup a decent build process.

We strongly recommend implementing Continuous Integration wherever possible as automation of an early feedback loop. In our experience the costs of initial set up has always been far outweighed by the quality benefits even without extensive unit tests.