読者です 読者をやめる 読者になる 読者になる

なみひらブログ

学んだことを日々記録する。~ since 2012/06/24 ~

継続的デリバリー

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

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

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

 

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

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

 

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

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

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