CIについて結構理解できると思う
背景
業務でGithub action導入検討をしていた際に、
CI(Continuous Integration（継続的インテグレーション)）が何に対しての概念なのか
主に以下のように混乱
「４つの混乱」(ハゲそうであった)
① 人間が細かく統合するから継続的な統合なのか。
② 統合した内容をルールのふるいにかけるから、統合先が常に安全であることなのか。
③ 統合のワークフローを自動化しているから継続的統合なのか。
④ CIは何かツールが導入されたから保証されるものではなく、
人間が意識してコードを統合する必要があるのか。
CIの定義をgithubを使ったチーム開発で考えた
CIとは「開発者が変更を共有 main へ頻繁に統合し、統合のたびに自動で検証して、main を常に健全に保つ、というチームの実践」
4つの混乱への回答
①「人が細かく統合するから継続的な統合なのか」
→ これが一番「名前の由来」に近い。Continuous（継続的）という語は、人が統合する頻度を指している。サーバが自動で動くことではなく、人が何度も main に合流する習慣のこと。歴史的にもツール以前からこの意味。
②「ふるいにかけるから統合先が常に安全であること、なのか」
→ これは目的・結果です。ふるい（検証）は手段で、その結果として得たい状態が「main が常に安全」。CIが生み出したい価値の側面。
③「ワークフローを自動化しているから継続的統合なのか」
→ これは道具・手段です。①を安価にし②を信頼できるものにする。でも自動化はCIの定義ではない——ツールはJenkinsでもActionsでも外部CIでも入れ替え可能で、入れ替えてもCIはCIのまま。
④「ツールで保証されるものでなく、人が意識して統合する必要があるのか」
→ 正しい。③（道具）は必要だが①（規律）の代わりにはならない。Actions を入れても、皆が長命ブランチを抱えていればCIは成立しない。
「混乱」の原因
混乱の元は、「CI」という語が3つの違うものに使い回されていること。
ひとつは実践としてのCI（本体）＝頻繁に統合し検証し続けるチームの行為。
ひとつは状態としてのCI＝main が継続的に統合済み・健全（②）。
ひとつは口語のシステムとしての“CI”＝「CIが赤い」「CIを設定する」と言うときの自動化基盤（③）。
混乱を感じるのは、この口語の③（道具）を実態だと思いかけて、でも①④（人の規律）とぶつかるから。
整理の鍵
CIは名詞ではなく動詞。「CIを持つ（ツールを入れる）」のではなく「CIをする（小さく頻繁に統合し検証し続ける）」。パイプラインはその実践のための電動工具で、実践そのものではない。だからCIの実態は「チームの習慣」＋「常に保たれる main の状態」であって、インストールする物でも一度きりのイベントでもない。
日常に例えた場合と破綻点
「ツール導入でCIが保証される」と思うのは、ジムの会員証を買えば健康になると思うのに似ている。会員証（ツール）は手段で、実態は通って動き続ける習慣（規律）とその結果保たれる体の状態（健全な main）。
破綻点
健康習慣は本人だけで完結しますが、CIは共有 main という1つの対象を、チーム全員で健全に保つ協調行為。一人が長命ブランチを抱えれば全体の統合が壊れる。個人完結のジム通いとは違い、CIは「みんなで同じ池をきれいに保つ」性質
まとめ
CIの実態は、ツールでも一回の作業でもなく、「人が main へ細かく統合し続ける習慣（①）」を「自動検証という道具（③）」が安価に支え、その結果「main が常に健全（②）」に保たれる——という継続的なチームの実践。だから「ツールを入れたら保証される」ではなく（④）、人がその習慣を回し続ける限りにおいて成立する。