継続的デリバリー

本文は、以下の書籍を参考にしました。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリーで大切なことは、

• 「我々が最も価値を置くのは、価値のあるソフトウェアを早いうちから継続的にデリバリーすることを通じて顧客を満足させること」
• 「好きなときに、好きなバージョンのソフトウェアをデリバリーできる」

品質の高いソフトウェア製品を届け続けるためのリリース手順（デプロイパイプライン）の一例を以下に示します。

-------------------------------------------------------------------------------

1. 開発チームの誰かが変更をコミットする。
2. 継続的インテグレーションサーバ（以下CIサーバ）が変更検知し、ビルドを行う。（コミットステージ）
3. 成功したら、オブジェクトとレポートおよびメタデータが成果物リポジトリに格納される。
4. CIサーバがコミットステージで生成されたオブジェクトを取得し、結合テスト環境にデプロイする。
5. CIサーバが受け入れテスト（WebAPIテスト、UIテスト）を実行する。その際、コミットステージで生成された オブジェクト を再利用する。
6. 成功したら、リリース候補に受け入れテストを通過したというフラグが立てられる。
7. テスターは、受け入れテストを通ったビルドの一覧を入手することができ、ボタン１つで自動プロセスを実行して、手動テスト環境にデプロイできる。
8. テスターが、手動テストを実施する。（テスターがテストするのはLook&Feeling、見た目と使い勝手）
9. 手動テストがうまくいったら、テスターがリリース候補のステータスを更新し、手動テストを通過したことを示す。
10. CIサーバが、受け入れテストや手動テストを通過した最新のリリースを成果物リポジトリから取得し（どちらを取得するかは設定による）、そのオブジェクトをステージング環境にデプロイする。
11. キャパシティテスト （ 性能/負荷テスト）をリリース候補に対して実行する。
12. 成功したら、リリース候補のステータスを「キャパシティテスト完了」に更新する。
13. このパターンは、パイプラインでの必要に応じていくつものステージで繰り返される。
14. リリース候補が関連するステージを全て通過したら、「リリース準備完了」となり、適切な承認を受けた上で、誰でもリリースできるようになる。通常、この承認行為は、QAと運用担当者が一緒になって行う。
15. リリースプロセスの最後に、リリース候補のステータスは「リリース済」となる。