開発プロセス・方法論

CI/CD

（しーあいしーでぃー）

一言でいうと

変更をこまめに統合し、動く状態を保ったまま届け続ける仕組みです。統合の間隔をどこまで短く保てているかで、同じ語でも実態は大きく変わります。

Martin Fowlerが2000年に書いた記事が起点です。その後も改訂を重ねており、著者自身の記述では2001年になっています。同記事は、この実践が現在ではトランクベース開発と呼ばれる場合があることにも触れています。

CIは統合の話、CDは配信の話で、本来は別の実践です。日本の求人票ではまとめてCI/CDと書かれることがほとんどですが、統合まで自動化していて配信は手作業、という組織も珍しくありません。

各自の作業が長く分岐したままだと、統合の時点でぶつかります。分岐している期間が長いほど衝突は大きく、解決に時間がかかります。統合を毎日、あるいは1日に何度も行うことで、一度あたりの衝突を小さく保つのが狙いです。

配信側も同じ理屈です。リリースを小さく頻繁にすれば、問題が起きたときに原因の範囲が絞られ、切り戻しも速くなります。

変更を短い間隔で共通のブランチへ統合し、そのたびに自動でビルドとテストを走らせます。壊れたらその場で直すことを最優先にします。テストが遅いと開発者が待てなくなり、統合の間隔が伸びて仕組みが形骸化するため、実行時間の管理も設計に含まれます。

配信側は、テストを通った成果物をいつでも本番に出せる状態に保ちます。出すかどうかの判断と、出せる状態にあることは分けて扱います。

自動化の基盤があること自体は読み取れますが、成熟度まではわかりません。この語が書かれていない求人のほうが今では珍しくなっています。

検索に使うなら、この語ではなくツール名です。要件に書いても差はつきません。

自社側で押さえるのは、テストの実行時間と、ビルドが壊れたときの扱いです。実行時間には10分を超えると統合の頻度が落ちるという古典的な目安があり、そこを大きく超えていれば改善の余地が残っています。候補者には、壊れたビルドを誰が直す運用だったかを聞きます。