プロダクトのリリースと環境について考えてみた

とあるプロジェクトを例として、リリース関連でやっていることをご紹介します。

#プロダクトマネージャー（PdM）

藤井元貴

2020.12.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

プロダクト開発とリリースは、切っても切れない関係にあります。本記事では、とあるプロジェクトを例として、リリース関連でやっていることをご紹介します。

前提

スクラムで開発しています
1スプリントは1週間です

環境と環境に合わせたリリースの紹介

4つの環境がある

目的に合わせて4つの環境があります。

環境名	位置づけ
開発環境	開発チームが開発するための環境
レビュー環境	レビューするための環境
ステージング環境	本番同様に使ってテストする環境
本番環境	エンドユーザが使う環境

リリースのGo判断をする人とリリースのタイミングは、大まかに下記となります。

リリース	Go判断する人	リリースタイミング
開発環境→レビュー環境	開発チーム	レビュー準備をするとき
レビュー準備→ステージング環境	プロダクトオーナー	決まっているリリース日時
ステージング環境→本番環境	プロダクトオーナー	決まっているリリース日時

開発環境

開発チームが開発するための環境です。各種実験などもここで行います。開発チームが主体となって動作確認を行います。開発チームがスプリントレビュー望めると判断したあと、レビュー環境にリリースを行います。

レビュー環境

スプリントで作成したものをデプロイします。そのため、このレビュー環境でスプリントレビューを行い、フィードバックを行います。ぶっつけ本番でレビューするのではなく、開発チーム内でリハーサルをしておくと安心します。そして、ステージング環境へのリリース判断は、プロダクトオーナーが行います。

ステージング環境

本番さながらの環境で動作確認をします。ここはチームによって考え方が大きく変わるとは思いますが、大事な点は下記だと考えています。

本番環境へのリリースGo判断の基準は何か？
誰が何を確認するのか？
どれぐらいの確認時間が必要なのか？

たとえば、あらかじめ決められた動作確認チェックシートを使って動作確認をする場合もあれば、社内で実際に使って安定稼働しているかを数日に渡って継続確認する場合もあるでしょう。そして、本番環境へのリリース判断は、プロダクトオーナーが行います。

本番環境

実際にプロダクトが使われる環境です。

リリース日時

あらかじめ日時を決めておくと分かりやすいです。スプリントレビューしたあとや翌日ぐらいがちょうど良いと思います。

9/02
- 11時〜：ステージング環境(v1.1.0)→本番環境(v1.1.0)
- 15時〜：レビュー環境(v1.2.0)→ステージング環境(v1.2.0)
9/09
- 11時〜：ステージング環境(v1.2.0)→本番環境(v1.2.0)
- 15時〜：レビュー環境(v1.3.0)→ステージング環境(v1.3.0)
9/16
- 11時〜：ステージング環境(v1.3.0)→本番環境(v1.3.0)
- 15時〜：レビュー環境(v1.4.0)→ステージング環境(v1.4.0)
9/23
- 11時〜：ステージング環境(v1.4.0)→本番環境(v1.4.0)
- 15時〜：レビュー環境(v1.5.0)→ステージング環境(v1.5.0)
9/30
- 11時〜：ステージング環境(v1.5.0)→本番環境(v1.5.0)
- 15時〜：レビュー環境(v1.6.0)→ステージング環境(v1.6.0)

「ステージング環境でどれだけ様子を見るのか？」は難しいです。私が関わっているIoT案件の場合は、デバイス側も含めた安定性の確認をする場合が多いため、1〜2週間ぐらい様子を見る事が多いです。Webサービスのようにスピード感が大切になる場合は、ステージング環境で問題ない場合はすぐに本番環境にリリースするのかもしれません（私は経験なし）。

リリース時のCI/CD

Gitのブランチ/タグと環境をどう対応付けるのかは悩むことが多いですが、ステージング環境・本番環境はタグのpushでリリースすると分かりやすいと考えています。タグをPushすることでCI/CDのワークフローが実行され、人間がApproveすることで各環境にリリースする形です。具体的には下記のイメージです。最初にタグをPushしておけば、あとはApproveボタンをポチッと押すだけでリリースができます。