!!! Overview
[{$pagename}] ([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.


[{$pagename}] was first named and proposed by [Grady Booch] in his [1991|Year 1991] method, although he did not advocate integrating several times a day. 


[{$pagename}] 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 [{$pagename}] server monitors the [Source-code Repository] and checks out changes when they occur
* The [{$pagename}] server builds the system and runs unit and integration tests
* The [{$pagename}] server releases deployable artefacts for testing
* The [{$pagename}] server assigns a build label to the version of the [code] it just built
* The [{$pagename}] server informs the team of the successful build
* If the build or tests fail, the [{$pagename}] 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:
[{ReferringPagesPlugin before='*' after='\n' }]