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

2013/5/30

自動ビルドやテスト環境を構築するときに、問題になることがある。そのひとつが、 ビルドを高速にしてフィードバックをすぐに得られるようにしたいけれども、包括的なテストをしようとすると時間がかかるということだ。 デプロイメントパイプラインは、ビルドをいくつかのステージに分割してこの問題に対処する。 ひとつのステージを通過するごとに信頼性が増すが、それぞれのステージにはそれなりの時間がかかる。 前半のステージで大半の問題をあぶり出してしまって素早くフィードバックし、 後半ではじっくり時間をかけた調査をする。 デプロイメントパイプラインは継続的デリバリーの肝となるものだ。

一般的に、デプロイメントパイプラインの最初のステージは、 何らかのコンパイルをしてバイナリを作るという作業だ。これを、それ以降のステージで使うことになる。 それ以降のステージの中には、自動化できないテストを手動で行うなどということもあるかもしれない。 自動的に進められるステージもあれば、誰かの承認が必要となるステージもあり得る。 そして、それらのステージを多数のマシンで並列実行すれば、ビルドの所要時間を短縮できるだろう。 本番環境へのデプロイは、パイプラインの最後のステージになることが多い。

より広い目で見ると、デプロイメントパイプラインの役割は、本番環境に影響を及ぼしうるあらゆる変更を検出することだ。 ここで言う影響には、パフォーマンスやセキュリティそして使い勝手といった問題も含む。 デプロイメントパイプラインは、ソフトウェアのデリバリーにいろんな役割で関わる人たちの共同作業を支えるものでなければいけない。 誰もがシステム上での変更の流れを確認できるようにして、監査証跡としても使えるものだ。

継続的デリバリーをうまく導入するには、まず現在のデリバリープロセスをデプロイメントパイプライン化してみればいい。 それを精査して、ボトルネックを探したりさらなる自動化の余地を見つけたり、共同でできる作業を検討したりする。

詳細な情報は、書籍『Continuous Delivery』 の第5章を参照すること。ここで、無料で読める。

謝辞

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