CI/CDとは何なのか？
iwatakaCI/CDのことを、「コードの変更をトリガーとした、ビルド・静的解析・自動テスト・パッケージング・デプロイ、等の一連の処理の自動化」といった意味で捉えている人が一定数いると感じている。実際そのような内容が中心的なのも事実だが、それだと本質を捉えていないと思っている。
まずCIについて考えてみよう。
CIを理解するためには、まずはContinuous Integrationという英語の意味を考えてみると良い。日本語に直訳すると「継続的インテグレーション」や「継続的統合」などとなる。ここで言う「インテグレーション」や「統合」が何を意味しているのかというと、「複数の開発者による変更のインテグレーション・統合」を意味していると自分は理解している。より具体的に言うと、Git等のバージョン管理システムを利用しているケースでは、featureブランチで開発した変更をdevelopブランチやmainブランチに統合することを指す。
つまり、CIというのは元来、コードの変更を継続的に統合することを指しており、それ自体は技術的な側面より、開発プロセス的な側面が強い内容となる。統合したコードを検証（verification）するという点において初めて、ビルド等の一連の処理を自動的に実行する、という内容が出てくる。
iwataka「コードの変更を継続的に統合する」という点で重要なものの１つが、Gitを始めとしたバージョン管理システムと、それを利用したブランチ戦略である。
バージョン管理システムは複数存在するが、現在はGitがデファクトスタンダードとなっている。
※「Gitが普及した理由」についての個人的な考察はこちらでまとめるつもり
ブランチ戦略については以下のように複数存在し（他にもたくさんある）、プロジェクトの特性によって選択が必要である。選択の観点については諸説あると思っているが、主に開発規模や開発プロセスによるところが大きい気がしている。
- git flow
- GitHub flow
- GitLab flow
- trunk based
iwataka冒頭で言ったような、「一連の処理の自動化」という意味でCIを捉えていると、単にシステム開発の工数削減というのがCIのメリットであるという考え方にたどり着いてしまう。しかしそれは、ビルド等の各処理の自動化によって得られるメリットであり、CI自体のメリットではない。
CIのメリットは、「コードの変更を継続的に統合」し、検証することによって、統合した際の問題を早期発見することであり、問題の解決を簡単にしたり、後工程で問題が発生するリスクを減らしたりすることにつながる。シフトレフトの考え方に近い。
iwatakaCIの参考文献として、自分は以下を推奨している。
今まで自分が書いた内容が詳細にまとまっているだけでなく、CIを実践する際の具体的なプラクティスが書かれており、そちらもCIを理解する上で把握しておきたい。