継続的デリバリのスモールスタート

継続的デリバリにはさまざまな概念やツールが関係するため、いざ導入しようとするとどこから手をつければ良いのか迷うと思います。また、最初から何もかもやろうとすると、目的を見失って、意味のない作業に追われてしまう危険性が高いです。今回のブログでは、継続的デリバリの目的とスモールスタートについて私の考えを書きます。

継続的デリバリの目的(私の解釈)

継続デリバリは、アプリケーションを常に本番リリース可能な状態にするための営みです(こちらのサイトを参考)。そして、継続デリバリの考えは継続的インテグレーションが元になっています。継続的インテグレーションは、複数の開発者が作成・変更したソースコードを頻繁に統合してビルドする営みです(こちらのサイトを参考)。継続的インテグレーションの目的は、ソースコードの統合時の問題を早期に発見することだと言えます。継続デリバリは、ソースコードの統合とビルドに加え、デプロイと実行も頻繁に行います。継続的デリバリの目的は、アプリケーションのデプロイと実行時の問題を早期に発見することだと言えます。


スモールスタート

継続的デリバリの目的は、以下の2点を実施することでの実現できると思います。

  • Trunkでの開発
  • 要求レベルのテストの自動化
Trunkでの開発

継続的デリバリの実施には、継続的インテグレーションの実施は必然だと言えるでしょう。そして、継続的インテグレーションを実施するには、Trunkでの開発が大事です(詳しくはこちらを参照)。Trunkでの開発とは、SCMを運用するとき、Branchを作らずにTrunkだけで開発をすることを意味します。逆に、Trunkでの開発ができれば、後はTrunkを定期的にビルドするだけで、継続的インテグレーションができることになります。

要求レベルのテストの自動化

アプリケーションがデプロイできて実行できるかをチェックするには、本番環境に近い環境にデプロイしたアプリケーションに対して、要求レベルのテストを実施するのが良いでしょう。ただし、毎回手動で実施するのは時間がかかるため、自動化させたほうが良いです。デプロイの自動化はコマンドラインツールなど何かしら手段はあるでしょうし、要求レベルのテストの自動化も、さまざまなツールが存在します(ツールの例はこちらを参照)。なお、要求レベルのテストを自動で行っても、本番リリースするには手動のテストが必要だと思うので、継続的デリバリが目指す「本番リリース可能な状態」にはならないと思いますが、デプロイ・実行時に発生しうる問題を早期に発見するには十分でしょう。

さいごに

継続的デリバリを導入する際は、何もかも盛り込むのではなく、最初は上記2点を実施するための最小限のプロセスやツールに絞り、その他の部分は徐々に肉付けしていくのが良いと思います。