superior-delivery

優れたデリバリー

検証済みの変更を、再現可能で、変更履歴を追跡でき、復旧可能な経路で所定の環境へ移します。プロジェクト既存のデリバリーシステムを維持し、リリースの準備と外部デプロイの承認を分けてください。

デリバリーの契約を確立する

デリバリーワークフローを変更または実行する前に、以下を確認してください。

• デプロイ可能な単位、ソースリビジョン、バージョン、ターゲットプラットフォーム。
• 正式なパイプライン、ビルド、パッケージング、署名、リリースの設定。
• 環境、昇格順序、承認、認証情報、所有者。
• アーティファクトレジストリ、来歴、保持期間、不変性に関する要件。
• ランタイム設定、シークレット、依存関係、マイグレーション、互換性の期間。
• ロールアウト、ヘルス検証、一時停止、ロールバック、前方復旧の基準。
• ユーザーが求めているのが、設計、実装、ドライラン検証、パッケージング、公開、デプロイのいずれか。

デリバリーファイルの準備またはレビューの依頼から、公開、タグ付け、リリース、デプロイ、昇格、ロールバック、共有パイプライン設定の変更に対する承認があると推測してはいけません。

一度ビルドし、移動するものを特定する

バージョン管理、依存関係の解決、ビルド出力、コンテナー、パッケージ、チェックサム、署名、SBOM、来歴、レジストリ、リリースメタデータに関わる作業では、references/artifacts-and-release-integrity.md を参照してください。

• 各アーティファクトを、不変のソースリビジョンおよび再現可能な設定の証拠に関連付けてください。
• 環境ごとにバイナリを再ビルドするのではなく、検証済みの同じアーティファクトを環境間で昇格させてください。
• プラットフォームの契約で安全な公開値が明示的に求められている場合を除き、ランタイム設定とシークレットを配布可能なアーティファクトに含めないでください。
• 必須入力がない場合や曖昧な場合は失敗させ、不完全に組み立てられたリリースを黙って公開しないでください。
• 生成アーティファクトとロックファイルは、安易に再生成せず、リポジトリの所有権に従って扱ってください。

パイプラインを決定論的かつ最小権限に保つ

CI/CD ステージ、キャッシュ、マトリックス、認証情報、承認ゲート、環境昇格、再利用可能なワークフローコンポーネントを変更する場合は、references/pipelines-and-environment-promotion.md を参照してください。

• リポジトリのサプライチェーンポリシーに従い、ツールとアクションのバージョンを固定するか、許容範囲を制限してください。
• ジョブを完了するために必要な最小の環境、操作、期間に認証情報の適用範囲を限定してください。
• 信頼されていないプルリクエストの実行を、シークレットを扱うリリース作業から分離してください。
• ステージ間の依存関係と失敗の伝播を明示してください。
• 信頼できるキーと復元境界があるコンテンツだけをキャッシュしてください。キャッシュはアーティファクトの信頼できる唯一の情報源ではありません。

受け入れ済みのデリバリー契約が明示的に変更されない限り、チェックを弱めたり、権限を広げたり、必須ステップを任意にしたりして、失敗したゲートを回避してはいけません。

証拠と停止条件を定めてロールアウトする

デプロイの順序、マイグレーション、機能フラグ、カナリア、ブルーグリーンまたはローリングロールアウト、ヘルスチェック、トラフィックの切り替え、ロールバック、デプロイ後の検証については、references/rollout-rollback-and-verification.md を参照してください。

• 前提条件、観測可能な成功、失敗のしきい値、続行を承認する権限を持つ人またはシステムを定めてください。
• レディネスを、ライブネスおよびビジネスレベルの検証と区別してください。
• アプリケーションとスキーマの変更は、バージョンをまたいで調整してください。マイグレーションコマンドが成功しても、安全なロールアウトが証明されたことにはなりません。
• 証拠が不足している場合や、しきい値を超えた場合は一時停止してください。前のステージに時間を費やしたことを理由に続行してはいけません。
• 状態またはスキーマの変更が不可逆な場合は、ロールバックと前方復旧を区別してください。

明示的な承認と確認済みのターゲットなしに、本番トラフィックを流したり、共有インフラストラクチャを変更したり、デプロイコマンドを実行したりして、ロールアウトをテストしてはいけません。

検証して報告する

リポジトリでサポートされている検証方法を使用します。適切な範囲で検証してください。

• パイプラインの構文と設定
• サポートされているクリーンな状態からのビルドとパッケージ作成の成功
• 該当する場合は、成果物の内容、バージョン、チェックサム、署名、来歴
• シークレット値を漏らさずに、環境固有の設定参照
• 移行と互換性の順序
• 許可されている場合に限り、ドライラン、プレビュー、隔離されたデプロイ、またはターゲット環境のヘルスチェック
• 実際に実施した範囲でのロールバックまたは復旧手順

評価したリビジョンと成果物、実行したコマンドまたはジョブ、該当する場合はターゲット環境、確認されたゲート、実施した外部への変更、未検証のロールアウト条件を報告してください。ビルド、パッケージ、計画、またはローカルシミュレーションしか完了していない場合は、「デプロイ済み」と決して報告しないでください。

必要なスキルを限定的に組み合わせる

• パイプラインまたはリリースの検証で、相応のテスト戦略やフィクスチャ設計が必要な場合は、superior-testing を使用します。
• 移行の仕組み、データ互換性、バックフィル、スキーマの復旧には、superior-database を使用します。
• ロールアウトの要件を可用性目標、縮退運転、フェイルオーバー、または運用上の復旧が左右する場合は、superior-reliability を使用します。
• 認証情報の境界、サプライチェーンの信頼性、公開範囲、またはセキュリティゲートには、superior-api-security を使用します。
• リリース基準で代表的なキャパシティやレイテンシの証拠が必要な場合は、superior-performance を使用します。
• ビルド、リリース、デプロイ、ロールバック、または運用手順を長期的に参照できる形で整備する場合は、superior-docs を使用します。

焦点を絞ったパイプラインの変更を、明示的なスコープなしにホスティングの移行、プラットフォームの置き換え、または本番リリースへと広げないでください。