Continuous integration


Continuous integration (CI) ia a Software development practice of merging all Development Team working copies to a single shared Source-code Repository several times a day and each check-in is then verified by Continuous Delivery (automated build and Continuous testing) allowing the team to detect problems (Bugs and Vulnerability) early.

Continuous integration was first named and proposed by Grady Booch in his 1991 method, although he did not advocate integrating several times a day.

Continuous integration was adopted by Extreme Programming (XP) did advocate integrating more than once per day – perhaps as many as tens of times per day.

"Continuous Integration(CI) doesn’t get rid of bugs, but it does make them dramatically easier to find and remove"Martin Fowler, Chief Scientist, ThoughtWorks.

The practices#

  • Maintain a single Source-code Repository
  • Automate the build
  • Make your build self-testing using Continuous testing
  • Every commit should build on an integration machine
  • Keep the build fast
  • Test in a clone of the production environment
  • Make it easy for anyone to get the latest executable version
  • Everyone can see what’s happening
  • Automate deployment

How to do it#

  • Development Team members check out code into their private workspaces
  • When done, commit the changes to the Source-code Repository
  • The Continuous integration server monitors the Source-code Repository and checks out changes when they occur
  • The Continuous integration server builds the system and runs unit and integration tests
  • The Continuous integration server releases deployable artefacts for testing
  • The Continuous integration server assigns a build label to the version of the code it just built
  • The Continuous integration server informs the team of the successful build
  • If the build or tests fail, the Continuous integration server alerts the Development Team
  • The Development Team fixes the issue at the earliest opportunity
  • Continue to continually integrate and test throughout the project

Development Team responsibilities#

  • Check in frequently
  • Don’t check in broken code
  • Don’t check in untested code
  • Don’t check in code when the build is broken
  • Don’t go home after checking in until the system builds
Many Development Team develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high.

More Information#

There might be more information for this subject on one of the following: