TL;DR
チームのメンバーが少なくとも毎日、自分の変更をメインラインに統合し、統合のたびにテストを含む自動ビルドで検証するプラクティス。統合のエラーをすぐに見つけられる。Kent Beck が 1990 年代に Extreme Programming の一部として広めた。
なぜ必要か
Test-Driven React 第6章 によると、ESLint や Stylelint などのチェックは開発者のローカル環境でしか動かない。チーム全員にこの環境を強制するのは手間がかかるので、チェックを個々の開発者の環境から切り離す CI が欠かせなくなる。
仕組み
Martin Fowler は、CI の主なプラクティスとして次を挙げている。
- 毎日メインラインにコミットする: Kent Beck の目安は、統合されないまま数時間を超えて残るコードがないことである
- ビルドにテストを含める: 十分なテストスイートが前提になる
- 壊れたビルドをすぐ直す: ビルドを直すことより優先度の高い作業はない。原因のコミットを戻すのが早いことが多い
- ビルドを速く保つ: XP の目安は 10 分である
注意点
フィーチャブランチで CI サービスを動かしても、変更がメインラインに入らないので、Fowler はそれを CI とは呼ばない。CI サービスは CI を助ける道具であって、プラクティスそのものではない。