Overview#
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
- 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.
There might be more information for this subject on one of the following: