Zenn
Open4

CI/CDとは何なのか？

CI/CD
iwatakaiwataka

CI/CDのことを、「コードの変更をトリガーとした、ビルド・静的解析・自動テスト・パッケージング・デプロイ、等の一連の処理の自動化」といった意味で捉えている人が一定数いると感じている。実際そのような内容が中心的なのも事実だが、それだと本質を捉えていないと思っている。

まずCIについて考えてみよう。
CIを理解するためには、まずはContinuous Integrationという英語の意味を考えてみると良い。日本語に直訳すると「継続的インテグレーション」や「継続的統合」などとなる。ここで言う「インテグレーション」や「統合」が何を意味しているのかというと、「複数の開発者による変更のインテグレーション・統合」を意味していると自分は理解している。より具体的に言うと、Git等のバージョン管理システムを利用しているケースでは、featureブランチで開発した変更をdevelopブランチやmainブランチに統合することを指す。

つまり、CIというのは元来、コードの変更を継続的に統合することを指しており、それ自体は技術的な側面より、開発プロセス的な側面が強い内容となる。統合したコードを検証（verification）するという点において初めて、ビルド等の一連の処理を自動的に実行する、という内容が出てくる。

iwatakaiwataka

「コードの変更を継続的に統合する」という点で重要なものの１つが、Gitを始めとしたバージョン管理システムと、それを利用したブランチ戦略である。

バージョン管理システムは複数存在するが、現在はGitがデファクトスタンダードとなっている。
※「Gitが普及した理由」についての個人的な考察はこちらでまとめるつもり

ブランチ戦略については以下のように複数存在し（他にもたくさんある）、プロジェクトの特性によって選択が必要である。選択の観点については諸説あると思っているが、主に開発規模や開発プロセスによるところが大きい気がしている。

  • git flow
  • GitHub flow
  • GitLab flow
  • trunk based
iwatakaiwataka

冒頭で言ったような、「一連の処理の自動化」という意味でCIを捉えていると、単にシステム開発の工数削減というのがCIのメリットであるという考え方にたどり着いてしまう。しかしそれは、ビルド等の各処理の自動化によって得られるメリットであり、CI自体のメリットではない。

CIのメリットは、「コードの変更を継続的に統合」し、検証することによって、統合した際の問題を早期発見することであり、問題の解決を簡単にしたり、後工程で問題が発生するリスクを減らしたりすることにつながる。シフトレフトの考え方に近い。