『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』を第二部まで読んだので、まとめておく。筆者らが〈デプロイメントパイプライン〉と呼ぶ、アプリケーションのビルド・デプロイ・テスト・リリースを自動化する実装パターンを紹介している。
〈デプロイメントパイプライン〉は、継続的インテグレーション[1]の考え方を突き詰めたもので、で目的はこの3つ。
- ソフトウェアのビルド・デプロイ・リリースというプロセスのあらゆる部分を関係者全員から見えるようにし、共同作業をやりやすくすること。
- フィードバックを改善し、プロセスにおいてできる限り早い時間に問題が特定されて解決されるようにすること。
- ソフトウェアの任意のバージョンを任意の環境に完全に自動化されたプロセスを通じて好きなようにデプロイできるようにすること
反対にこんなアンチパターンに陥っていると、プロセスが不明瞭でフィードバックが遅くてデプロイがいちいち大変。どれも心当たりがあって、どうダメなのか解説されるのを読んでいると、頭を抱えたくなってくる。
- ソフトウェアを手作業でデプロイする
- 開発が終わってから疑似本番環境にデプロイする
- 本番環境について手作業で構成管理を行う
こんなアンチパターンから抜け出すために、インクリメンタルに実装していくのを薦めている。下記の通り扱っている範囲がとても広いから、一気には進められないだろう。単純に量が多いのもあるけれど、それ以上に関係者も多くなるから、やり方を変えるのに苦労しそう。
- 伝統的な構成管理
- ソースコードコントロール
- リリース計画
- 監査
- コンプライアンス
- インテグレーション・ビルド・テスト・デプロイといったプロセスの自動化
- 受け入れテストの自動化
- 依存関係の管理
- データベースの移行
- テスト環境や本番環境の構築と管理
[1] 『継続的インテグレーション入門』に詳しい。主にデプロイメントパイプラインではコミットメントステージ（コンパイル・ユニットテスト・分析・ビルド）に相当する範囲を扱っている。