ワークフローを、ソフトウェアと同じ流儀で出荷する
変更は変更セットとして計画され、実行され、その後0〜100%の重みでバージョン間に配分されます。新しいバージョンは、すべてを引き受ける前に実トラフィックの一部で実力を示します。
レビュー可能な変更セット、0〜100%の重みによるバージョン間のトラフィック配分、環境をまたぐ設定の昇格。
変更が出荷されるまで
- レビュー可能な変更セットとしてデプロイ — デプロイはまず計画され、何が変わるのかを変更前に確認できます。その上で実行、あるいは中止します。各段階は監査され、リソース変更はそのデプロイに紐づくため、リリースは散らばった編集ではなくひとつのまとまりとして読めます。
- バージョン間の重み付けトラフィック — 受信イベントの一定割合を新バージョンに振り分け、残りは旧バージョンのままにできます。まず5%だけ流し、監視画面でエラー率を見てから割合を上げる——あるいは戻す。再デプロイは不要です。
- 環境をまたいで設定を昇格 — ワークスペースの設定をエクスポートし、別の環境へインポートできます。既に存在する項目をどう扱うかは明示的に選べます。ステージングは、本番が既に知っていることを打ち直す場所ではなくなります。
- 環境ごとの変数とシークレット — 同じワークフロー定義が、動く場所に応じて別のエンドポイントと認証情報を指します。昇格ではワークフローの構造だけが移り、本番の鍵がテスト環境に持ち込まれることはありません。
プラットフォームの機能
- 0〜100%: バージョンごとのトラフィック配分
- 計画 → 実行: 適用前に変更内容を確認
- エクスポート／インポート: 環境間で設定を移動
新しいバージョンを段階的に出せますか？
はい。トラフィックは0〜100の重みでバージョンに割り当てられます。新バージョンを実イベントのごく一部から始め、旧バージョンとエラー率を比較し、再デプロイなしで重みを上げ下げできます。
デプロイ時、すでに実行中のものはどうなりますか？
バージョンは置き換わるのではなく併存するため、実行は開始したバージョンのまま進みます。重みが決めるのは新しいイベントがどのバージョンに入るかであり、進行中の処理を書き換えることはありません。
環境ごとにワークフローを作り直す必要がありますか？
いいえ。設定はひとつのワークスペースからエクスポートし、別のワークスペースへインポートします。既存のものをどう扱うかは競合戦略で指定できます。変数とシークレットは環境に紐づいたままなので、移動するのは定義であって認証情報ではありません。