本番へ昇格する

/git release の段取り

本番（prod）は、利用者が実際に使う環境です。公開前に「今回含める変更」「検証環境（stg）で試した結果」「公開する候補の番号」を担当者と確認します。たとえば「申込期限の変更を含む候補○○を本番へ公開してください」と、対象を指定して承認します。同じ候補を承認済みなら取り直しは不要ですが、対象が変われば改めて確認します。

作り直さず、そのまま昇格する

サーバーで動かすアプリ一式を、配備用の荷物（コンテナイメージ）にまとめます。5slabでは stg で試した荷物を作り直さず、そのまま本番へ使います。候補には、コードの版を識別するSHAと、荷物の内容を識別するdigestが記録されます。担当者は両方を照合し、確認したものと違う荷物が公開されるのを防ぎます。

承認する人が長い識別番号を暗記する必要はありません。変更一覧と検証結果が同じ候補のものかを確かめます。通常の公開は、今の本番から前へ進む版だけが対象です。古い版へ戻すときは、下のロールバック手順を使います。処理の失敗や結果不明のときは、再実行の前に担当者が状況を調べます。

リリースノートと稼働の記録

公開が成功すると、自動処理がGitHub Releaseに変更の一覧を残します。この5Sラボのサイトの「リリースノート」ページでも公開内容と稼働の記録を確認できます。担当者から成功の報告を受けたら、本番のURLで依頼した操作を試しましょう。開始の通知や、過去に付いたタグだけで完了と判断しません。

押さえておきたい用語

昇格

検証環境で確認したアプリを作り直さず、本番へ反映すること。

確認済み候補

配備と自動検査の成功を記録した版。人による業務確認は別に行い、その候補を承認する。

SHA

コードの版を識別する値。どの変更を含む版かを確かめるために使う。

digest

配備するアプリ一式の内容から計算した識別値。同じものを配備したか照合するために使う。

releaseタグ

成功した本番反映の版に付ける印。現在の状態は配備記録や稼働する版とも照合する。

ロールバック

本番のアプリを過去の版へ戻すこと。業務データやデータベースの構造は自動で戻らない。