リリースパイプラインとは何か？ビルドを本番へ届ける

リリースパイプラインは、すでにビルドされテストされたartifactを取り、環境を通して本番へ移動させます。多くの場合、承認とpromotion stepを伴います。

コードがビルドされテストされたら、それを安全にユーザーへ届けることは別の関心事です。リリースパイプラインがそれを扱います。検証済みのartifactを拾い上げ、staging、承認を経て本番へと導きます。CIパイプラインが「このコードは良いか？」に焦点を当てるのに対し、リリースパイプラインは「どうやって安全に出荷するか？」に焦点を当てます。

リリースパイプラインがカバーするもの

テスト済みのartifactを環境間でpromoteする。
本番前の承認ゲート。
各環境への実際のデプロイ。
デプロイ後チェックとrollbackの経路。

リリース vs CIパイプライン

CIパイプラインは変更を検証します（build、test、scan）。リリースパイプラインは検証済みのビルドを取って届けます。多くのチームはそれらを分離して保ち、リリースがすべてのCIを再実行せずにオンデマンドで実行できるようにします。

簡単な例

リリースパイプラインはイメージ app:${VERSION} を取り、stagingへデプロイし、smoke testを実行し、手動承認を待ってから、同じイメージを本番へpromoteします。artifactは環境間で決して変わりません。

安全機構

リリースは本番に触れるため、承認、環境保護、段階的なrollout、rollbackのjobに頼ります。目標はリリースを退屈にすることです。予測可能で、可逆的で、可観測にすることです。

リリースの信頼性

不安定なインフラで失敗するリリースパイプラインは、デプロイを中途半端に残しかねません。安定したエージェントと一時的なエラーでの自動retryがここで最も重要です。マネージドランナー（Latchkey）はインフラの一時的な不具合をretryするので、リリースは本当に何かがおかしいときにのみ失敗します。

重要なポイント

リリースパイプラインは、テスト済みのartifactを安全に本番へ届けます。
CIとは別です。CIは検証し、リリースは出荷します。
承認、promotion、デプロイ後チェック、rollbackに依存します。