Continuous Integration Environments

Operations refers to the services and service management provided to the Software Development business and/or its customers. Operations includes services such as environment provisioning, networking, support, asset management, service management, estate management etc.

Continuous Integration Environments are a configuration of storage, processing and computing resources used to automatically integrate a product, automating production of Team Builds including some quality assurance activities.

Continuous Integration infrastructure may be virtual or physical, ranging from simple xAMP servers to elastic cloud based services. Changes from team members will either be pushed or pulled into an Integration Stream accessed or managed by the Continuous Integration Environment.

Development teams will need to create and change continuous integration environments dynamically and so they are best provisioned as part of Platform-as-a-Service.

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.

Integration Streams

Integration Streams combine the output of multiple developers, and/or from multiple contributing teams in a complicated or complex system. They also provide a staging mechanism for testing prior to promotion from “build” to “release” enabling progression through the levels of done. Integration Streams are typically implemented as “streams” or “branches” in version control tooling.