なぜ我々は継続的インテグレーション、継続的デリバリするのか

これは ギルドワークスイベントカレンダー 3日目の記事となります。

ギルドワークスでは、プロジェクトを開始したときに、多かれ少なかれ、継続的インテグレーションや継続的デリバリの仕組みを組みます。今日は改めて、なぜそのような仕組みをととのえているのか、整理して見たいと思います。

継続的インテグレーションと継続的デリバリ

その前に、改めて用語を整理しておきましょう。

継続的インテグレーション（CI）とは、ソースコードを継続的に結合（Integrate）することです。

JavaやC#などコンパイルを行う言語では、「継続的ビルド」とも言います。ビルドすることそのものが、結合に当たるからですね。

一方、Rubyなどの動的言語では、簡単な単体テストを使って、結合を確認することが多いでしょう。（もちろん、Javaなどでも単体テストを含めることはあります）

継続的デリバリ（CD）とは、CIによって結合された成果物を、実際の環境に配置（Deploy）するところまで、継続的に行うことを指します。デプロイする場所は、ステージング環境や本番環境などが対象となるでしょう。

なお、最近はCIやCDという言葉を一時期ほど最近は効かなくなっているように思います。おそらく、DevOpsやSREといった、より大きな開発フレームワークの中での「当たり前」として、定着しつつあるのかなと思います。

なぜわざわざCI/CDを行うのか

ここで、ポイントになってくるのが「継続的」ということです。一体何を持って「継続的」というのでしょうか。

CI/CDの文脈での「継続的」とは、Gitなどのバージョン管理システムへのcommit/pushを指すことが多いです。そしてそれを実現するためには、コード一発の実行でデプロイが可能になる仕組みが必要です。

では、CI/CD = コードによるビルドやデプロイなのでしょうか。

いいえ、仮にコードによるビルドやデプロイが実現できていたとしても、それが継続的に実行されていないと、その効果は大きく減衰します。

それは、自動ビルドは「当たり前」のベースラインを作るためのものだからです。

git push をすれば、サーバー側でコードの正当性を見てくれる。

masterにブランチがマージされれば、サーバーが更新される。アプリが配信される。

そのような「当たり前」を作ることが重要なんです。当たり前という意識がないと、それが崩れたときに、回復力が働きません。壊れたビルドが放置され、近い将来、自動化コードは遺産ではなく、遺物（≒ 負債）になります。（どちらも英語だと legacy なんですよ！）

まずは、小さく始めよう

とはいえ、私達も完璧ではありません。まだまだ、改善すべきポイントはたくさんあります。しかし、どんなプロジェクトであっても、まず何か1つ、結合してみましょう。コンパイルでもいいです。物凄くシンプルなテストでもいいです。なんなら、Lintなどの静的解析でもいいです。

そしてそれを、「当たり前」にしましょう。ビルドが通っているのは当たり前、 npm serve が動くのは当たり前、静的解析で警告レベルが一定値以下なのは当たり前。

どんなプロジェクトでも、そこにベースを作ることはできます。そして、そこから改善を重ねていくことができます。

良い、Kaizen Journey を！