http://martinfowler.com/bliki/ContinuousDelivery.html

継続的デリバリーはソフトウェア開発における規律のひとつだ。 この規律に従ってソフトウェアを作れば、いつでも本番環境にリリースできるようになる。

継続的デリバリーをしているといえるのは、以下を満たしているときだ1

  • そのライフサイクルを通して、どの場面でもソフトウェアをデプロイできる。
  • チーム内で、新たな機能を追加することよりもソフトウェアをデプロイできるようにすることを重視している。
  • 誰かがシステムに手を加えたときに、それが本番環境にリリースできるかどうかを、誰でもすぐに自動的にチェックできる。
  • どのバージョンでもどんな環境向けでも、必要に応じてボタンひとつでデプロイできる。

継続的デリバリーを実現するには、開発チームがソフトウェアを継続的に統合し、実行ファイルをビルドして、 さらにそれを自動的にテストして問題を検出すればいい。 さらに、その実行ファイルを疑似本番環境に置いて、本番環境でもきちんと動作することを確かめる。 そのために使うのがデプロイメントパイプラインだ。

重要なポイントは、顧客から 今開発中のそのバージョンを、すぐに本番環境にデプロイしろ と言われたときに対応できるかどうか、そして誰もパニックに陥らずに済むかどうかということだ。

継続的デリバリーを実現するために必要なことは、次の二点だ。

  • デリバリーにかかわるすべての人たちの間できちんと連携し、共同で作業を進める(いわゆる「DevOps」ってやつだ)2
  • デリバリープロセスを、可能な限り自動化する。一般的にはデプロイメントパイプラインを使う

たまに、継続的デリバリーと継続的デプロイメントをごっちゃにしている人がいる。 継続的デプロイメントとは、すべての変更がパイプラインを通り、自動的に本番環境まで行くということだ。 結果的に、一日に何度も本番環境へのデプロイが発生する。 継続的デリバリーとは、単に「やろうと思えばいつでもデプロイできるようにしておく」というだけのことで、 実際のデプロイはそんなに頻繁にはしないという選択肢もある。 業務的に、あまり頻繁なデプロイが好ましくないなどの理由であることが多い。 つまり、継続的デプロイメントをするためには継続的デリバリーが必須だということだ。

継続的インテグレーションは、開発環境の中での統合やビルドそしてテストを指すという考えかたが一般的だ。 継続的デリバリーはこれをベースにしたもので、最終段階を本番環境へのデプロイまでにするというものだ。

詳しい情報は、ガイドページからたどれる資料をあたって欲しい。 特にこの本を読もう。

謝辞

このページを書くにあたり、Jez Humbleにいろいろ助けてもらった。

  1. これらの指標は、ThoughtWorksの継続的デリバリーワーキンググループが考えたものだ。 

  2. 名前こそ「devops」だが、開発者と運用担当者だけが協力すればいいってわけじゃない。テスターとかデータベースチームとか、ソフトウェアを本番環境に載せるために必要なメンバー全員が参加しなければいけない。