次のデプロイを再現可能にする

識別可能な入力を収集する

非本番環境でビルドできるアプリケーション、ソースとその成果物レジストリへのアクセス、バージョン管理された設定スキーマ、外部シークレットストアを使用します。既知の動作するリリースを保持してください。これらは自動化への入力です。PrivacyNodesはこのウェブサイトを通じてデプロイAPIやパイプラインランナーを提供しません。

以下のような可変ラベルに頼らず、成果物をピン留めしてください: latest。Dockerは正確なベースイメージを識別するためのダイジェストピン留めを文書化しており、更新を意図的にレビューする必要があります。再現性とパッチ適用はどちらも責任です。古く脆弱なイメージを永遠に保持することはメンテナンス計画ではありません。

技術リファレンス: Dockerビルドのベストプラクティス.

トラフィックを変更する前にリリース記録を書く

これは実行可能スクリプトではなく文書形式です。レビュー済みの成果物からプレースホルダーを埋めてください。ソースリビジョンだけでは環境の変更を説明できません。観察されたマイグレーション所要時間、予想されるロック動作、設定の差異、最後に動作した成果物を含めてください。

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

アプリケーションがダウンしているときにも到達できる場所に記録を保管してください。保護されたリカバリ認証情報はその値を含めずに参照してください。昇格を停止できる保守担当者と、計画されたロールバックがもはや有効でなくなる時点を明記してください。

準備と昇格を分離する

まず成果物をビルドして検査します。新しいプロセスを開始する前に設定とシークレット参照を検証します。このリリースでレビューされたスキーマ手順のみを適用します。新しいバージョンを意図した環境で起動し、トラフィックを移す前に依存関係を確認します。レビューされていない破壊的マイグレーションと通常のイメージ更新を組み合わせることは避けてください。

Composeでは、コンテナが起動しただけでは準備完了を意味しません。意味のあるヘルスチェックと condition: service_healthy は依存関係の待機を有用にできますが、顧客ワークフローを検証することはできません。アプリケーションは起動後に依存関係が利用不能になる場合にも対処する必要があります。

技術リファレンス: Docker Compose の起動順序.

グリーンのポート以上を検証する

レポーティング API では、認証済みテストリクエスト、意図したスキーマに対する読み取り、小さなキュー投入エクスポート、およびそのファイルへのアクセスを確認します。専用のテスト名前空間を使用し、本番通知を抑制します。重複するバージョンがスケジュールされた作業を誤って二重化しないことを確認します。

確認の前に期待される出力を記載します。正しいアカウントスコープ、期待されるサンプルレコード、1 件の完了したエクスポート、および不正なクロスアカウントデータがないことです。その後、実際の出力とタイミングを記録します。ホームページが HTTP 200 を返しても、ワーカーが繰り返し失敗したり、マイグレーションによって API が古い値を読み取ったままになっていれば不十分です。

リカバリ判断を明示する

プロセスが起動に失敗した場合は、動作中のバージョンでトラフィックを維持します。ワークフローチェックが失敗した場合は、プロモーションを停止し、編集済みの証拠を保全します。古いアーティファクトと互換性のある追加的なスキーマ変更であれば、アプリケーションのロールバックが可能な場合があります。非互換の変換後は、古いコードが安全でない可能性があります。レビュー済みの前方修正またはデータ復旧計画に従ってください。

失敗するマイグレーションを無期限に繰り返さないでください。何がコミットされたか、再試行が安全か、ユーザーが新しいスキーマの下で書き込みを行ったかを判断します。 マイグレーションガイド では、カラム変更を例にこの境界を詳しく説明します。ロールバックボタンの存在を、データを元に戻せる証拠として扱わないでください。

別の保守担当者が追える記録を残す

デプロイされたアーティファクトと構成の識別子を、計画記録と比較します。チェック、失敗した試行、および選択した復旧アクションを保全します。最後に動作したアーティファクトを明示的な保持ポリシーの下に置き、検証が不完全な間は削除しないでください。

有用なリハーサルでは、別の権限を持つメンテナーが入力内容を説明し、チェックを繰り返し、シェル履歴を検索することなく復旧手順を見つけられます。ゼロダウンタイムや将来の成功を証明するものではありません。スキーマ、ワーカーの動作、依存関係が変わったときに見直してください。次に、範囲を絞り込みます。 デプロイ ID の権限.