Continuous Integration

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed by Grady Booch in his 1991 method,[1] although practices at this time did not yet support full automation, or the performance of integrations more than a few times a day. It was adopted as part of Extreme Programming (XP), which did advocate integrating more than once per day, perhaps as many as tens of times per day. The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each.

Continuous integration (CI) is the combination of practicing trunk-based development and maintaining a suite of fast automated tests that run after each commit to trunk to make sure the system is always working.

cf Continuous Delivery

Eval of some hosted tools by members of a closed list:

  • Travis - Big dog, reliable, but a little older & less innovative.
  • Drone.IO - Hackers delight
  • Circle C I - Several thumbs up..
  • Code Ship - Solid performance, occasional service interruptions & not as customizable as some others.
  • Atlassian Bamboo - Solid, but costly. (Actually pretty cheap for entry-level.)

Edited:    |       |    Search Twitter for discussion