『継続的デリバリー』 第5章 学習メモ
デプロイメントパイプラインを解剖する
1.はじめに
継続的デリバリーにおける、デプロイメントパイプラインについての調査記録です。
継続的デリバリーの中での、デプロイメントパイプラインの責務や構成について記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第5章に対応します。
2.概要・目的
デプロイメントパイプラインでは、まず、CIでシステムをコントロールする。
また、デプロイメントプロセスを自動化することで、アクセスの容易さとフィードバックの高速化を実現し、速さと安全さを提供する。
ビルド・デプロイ・テスト・リリースプロセスを自動化することで、最終的にプルシステムが構築でき、デプロイメントパイプラインは自由と柔軟性をもたらす。
3.対応概要
(1)デプロイメントパイプラインによるプロセスのモデル化
デプロイメントパイプラインとは、ソフトウェアをバージョン管理から取り出してユーザに手渡すまでのプロセスを自動化して表現したものである。
コンセプトから対価の獲得までのプロセス全体は、バリューストリームマップとしてモデル化できる。
継続的デリバリーでは、バリューストリームのうちの、開発からリリースまでの間を扱う。
バージョン管理における特定のリビジョンが、パイプラインに対するインプットとなる。
デプロイメントパイプラインのパターンを適用することで、以下の恩恵を得られる。
- ビルドを徹底的にテストすることで、不適切なビルドを本番にリリースしてしまうことを効率的に避けられる。また、リグレッションバグを避けられる。
- デプロイメントと本番リリースの自動化により、素早く、反復可能で信頼できるプロセスとなる。
以前のバージョンに戻すことも容易になり、リリースのリスクがなくなる。
デプロイメントパイプラインを実現するための、あらゆるプロジェクトに共通したサブセットは以下の通りとなる。
- コミットステージ
- 技術レベルの検証。
- 自動受入テストステージ
- 機能および非機能レベルの検証。
- 手動テストステージ
- ユーザ視点の価値の検証。
- リリースステージ
- システムをユーザにデリバリーする。
これらのステージと、その他のソフトウェアデリバリープロセスをモデル化するために必要なステージを合わせて、デプロイメントパイプラインと呼ぶ。
(2)基本的なデプロイメントパイプライン
参考文献の図5-4に基本的なデプロイメントパイプラインの構成図が載っている。
構成のポイントは以下の通り。
- バージョンコントロールと成果物リポジトリは、パイプラインのすべてのステージと関係する。
受入ステージ以降に対しては、バージョンコントロールは環境とアプリの設定を提供する。 - コミットステージと受入ステージの完了後は、UAT・キャパシティ・本番の各ステージに枝分かれする。
また、受入ステージの完了後は、デプロイメントのための自動スクリプトを使用し、手作業でデプロイする。
さらに、特定のチェックインとビルドを、パイプライン上で通過したステージに関連付けて可視化することも重要である。
4.対応詳細
(1)デプロイメントパイプラインのプラクティス
デプロイメントパイプラインのプラクティスとして、以下が挙げられる。
- バイナリのビルドは1回限りとし、ファイルシステムやCIサーバで管理する。
- バイナリを環境に対して疎結合にする。もろくコストの高いプロセスにしないため。
- あらゆる環境に対して同じやり方でデプロイする。
デプロイメントスクリプトは各環境で同じものを使い、各環境ごとに一意の設定は別々のプロパティファイルとし、バージョン管理に格納する。 - 環境に依存しないプロセスとすることで、デプロイの失敗の原因を限定できる。
- デプロイメントのスモークテストは、最優先のユニットテストスイートの次に優先するテストとする。
アプリケーションが依存するすべてのサービスに煙を流す。 - 本番のコピーにデプロイする。
環境が同一であることを示すために、以下を確認する必要がある。 - 各変更が直ちにパイプライン全体を通り抜けるよう、スケジューリングを行う。
受入テストが完了して初めて、CIは新しい変更を取得できる。
(2)コミットステージ
「ユニットテスト + コミットテスト用選抜テスト = コミットテストスイート」となる。
実行可能なコードの生成自体を成功基準として扱うことで、CIによりビルドプロセス自体を評価できる。
コミットステージが問題の大半を検出し、きわめて素早く実行できる必要がある。
これにより、後に続くテストステージが通ることを推測し、デプロイメントパイプラインの実行と並行して、新しいフィーチャの開発ができる。
(3)自動受入テスト
「機能の受入 + リグレッション = 受入テスト」となる。
受入テストのプラクティスとして、以下が挙げられる。
(4)後に続くステージ
デプロイメントパイプラインにより、テスターがあらゆるビルドをテスト環境に好きなようにデプロイできる。
手動テストでは、自動テストでうまくできないテストに集中する。
非機能のテストの結果に対する評価は人間が判断してもよい。
(5)リリースに備える
デプロイメントパイプラインが以下を達成することで、リリースの問題を緩和する。
- デリバリーにかかわるすべての人がリリース計画を作成し、保守する。
- 最もエラーの起こりやすいステージからプロセスを自動化し、ヒューマンエラーの影響を最小化。
- 疑似本番環境で行われるプロセスを繰り返すことで、プロセスやそのための技術をデバッグできる。
- 計画通りいかなかったときにバックアウトを可能にする。
- 設定と本番データを移行する戦略を、アップグレードとロールバックプロセスの一部とする。
リリースプロセスの完全な自動化が目標となる。
a.デプロイメントとリリースの自動化
本番環境の変更は、自動化されたプロセスを通じてのみ行われるべき。
これにより、信頼できる監査、問題の診断、修正にかかる時間の予期が可能となる。
また、本番環境を管理するプロセスは、ステージング環境やインテグレーションテスト環境といったその他の環境でも使う。
キャパシティテストのフィードバックにより、設定の変更を評価する。
環境のプロビジョニングと保守を自動化するコストは、自動プロビジョニングや環境の管理、適切な構成管理プラクティス、仮想化により大幅に低減できる。
リリースプロセスは、継続的に評価され、改善される必要がある。
b.変更のバックアウト
最善のバックアウト戦略は、アプリケーションの1つ前のバージョンをリリースの間も使えるようにしておくこと。
次善の戦略は、以前の適切なバージョンを1から再デプロイすること。
(6)デプロイメントパイプラインの実装
デプロイメントパイプラインを実装するためのステップは以下の通り。
ビルドとデプロイメントの自動化の要点は以下の通り。
- バイナリが開発ツールに依存しない
- CIサーバの設定
- デプロイメント先環境の用意
- 自動デプロイメントのテスト
- バイナリと設定の分離
コミットステージが5分を超えたら、いくつかのスイートに分割する。
パイプラインは以下のために拡張されうる。
- バリューストリームの進化
- コンポーネント
- ブランチ
パイプラインの実装のために、以下の3つのプラクティスがある。
- バイプラインはインクリメンタルに実装する。
- パイプラインの実装では、プロセスの開始時刻と終了時刻、またどの変更がプロセスの各ステージを通過したかを記録する。これにより、プロセスのボトルネックを特定できる。
- パイプラインのリファクタリングを実施する。
(7)メトリクス
ソフトウェアデリバリープロセスにとっての最も重要なメトリクスは、サイクルタイム。
サイクルタイムの短縮のために、以下のプロセスに従うことで、制約理論を適用できる。
- システムにとっての制約条件を特定。制約条件とはボトルネックのこと。
- ボトルネックの箇所のスループットを最大化。
- 他のプロセスをすべて制約に従属させる。
- 制約の限界を上げる。リソースを増やす。
- 繰り返す。
その他のメトリクスは以下の通り。
- 自動テストのカバレッジ
- コードベースの特徴
- 欠陥の数
- 速度
- 1日当たりのバージョン管理システムへのコミット数
- 1日当たりのビルド回数
- 1日当たりのビルド失敗回数
- 自動テストを含むビルドにかかる時間
5.影響・作用
デプロイメントパイプラインの目的は、デリバリーにかかわるすべての人にとって、チェックインからリリースまでのビルドの進展の可視化にある。
また、ボタン1つで手動テスト環境にデプロイでき、環境にどのリリース候補があるのかわかるようになる。
デプロイメントパイプラインを実装することで、リリースプロセスの非効率な部分を特定できる。
さらに、プロセスを分析するための情報を得られる。
6.おわりに
以上が、継続的デリバリーの中での、デプロイメントパイプラインの責務や構成です。
7.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第5章 デプロイメントパイプラインの解剖学
