specsfy-specialist-delivery-engineering

デリバリーエンジニアリング

使用する場面

• プロジェクトにパイプライン（CI/CD の *.yml）、リリース戦略、環境間の昇格、またはロールアウト／ロールバック計画がある場合に呼び出します。
• 特定の変更に対して、ローリング、ブルーグリーン、カナリア、またはフィーチャーフラグから選ぶ場合にも呼び出します。
• Swarm クラスター内の低レベルなデプロイを行う場合（$specsfy-specialist-docker-swarm を使用）、またはロールアウトが健全であることを示すシグナルを判断する場合（$specsfy-specialist-observability を使用）は呼び出しません。ここでは、パイプラインと昇格戦略の設計に焦点を当てます。
• パイプラインが本番環境の認証情報を扱う場合、または署名済みアーティファクトを公開する場合は、$specsfy-specialist-application-security と組み合わせます。

フロー

1. リリースまたは完全なデプロイでは、$specsfy-specialist-deploy のもとで作業し、アーティファクト、変更履歴、タグには $specsfy-specialist-versioning が用意した SEMVER を使用します。
2. パイプラインを設計する前に、コミット、アーティファクト、環境、必要な承認、各昇格の担当者を整理します。
3. バージョン管理されたロックファイルから、ビルドとテストを再現可能にします。ビルド時に「最新」の依存関係を解決してはいけません。
4. 不変のアーティファクトを一度だけ生成し、再ビルドせずに環境間で昇格させます（ステージングでテストしたバイナリと、本番環境で公開するバイナリはビット単位で同一です）。
5. ジョブごとに認証情報、権限、信頼境界を分離します。ビルドを行うジョブには、本番環境への公開に使う認証情報を持たせません。
6. ロールアウト期間を通じて、旧バージョンと新バージョンのアプリケーション間で互換性が保たれるよう、スキーマのマイグレーションを調整します（拡張／縮小）。
7. 最初の実デプロイの前に、ロールアウト戦略、客観的な成功シグナル、一時停止基準、ロールバックの仕組みを定めます。
8. アーティファクトの出所、バージョン、テストの証跡、ロールアウト結果を監査可能な形で記録します。

パターン

• 最小権限を適用し、長期間有効な静的シークレットではなく、一時的な認証情報（OIDC／STS）を使用します。また、パイプラインのアクションや依存関係は、可動タグ（@latest、@main）ではなく、ハッシュまたは正確なバージョンで固定します。
• 環境ごとにアーティファクトを再ビルドしません。一度ビルドし、署名するかダイジェストを生成して、同じ不変の参照を昇格させます。
• 互換性のない同時実行（同じサービスに対する同時の 2 件のデプロイ）を防ぎ、完全なテストパイプラインを通過していないコミットのデプロイを防ぎます。
• Infrastructure as Code を使用して、環境を再現可能な状態に保ちます。環境設定はアーティファクトの外部（環境変数、シークレットマネージャー）に置き、ビルドに埋め込んではいけません。
• ロールアウトの完了と見なす前に、機能的なスモークチェックと有効なオブザーバビリティを必須にします。「エラーなくデプロイが終わった」ことと「サービスが健全である」ことは同じではありません。
• コードのロールバック（以前のバイナリに戻すこと）とデータのロールバック（適用済みのマイグレーションを戻すこと）は、別々の問題として扱い、それぞれ異なる計画を立てます。すべてのマイグレーションをデータ損失なしで元に戻せるわけではありません。
• 誰が、いつ、何を、どの承認を得て昇格させたかを監査可能な形で記録し、ログや監査アーティファクトにシークレットを決して記録しません。

アンチパターン

• 各環境でイメージを再度ビルドするパイプライン（staging のジョブと本番環境のジョブでそれぞれbuildを実行する）：同じ Dockerfile を使っていても、staging でテストした成果物が本番環境にデプロイされるものと同一である保証はありません。「latest」として解決される依存関係や異なるキャッシュによって、異なるバイナリが生成されます。
• オーナーも有効期限もないフィーチャーフラグ：目的を誰も覚えていない使われなくなったフラグが蓄積し、テストされていない組み合わせの範囲が広がります。
• 古い列を削除するデプロイと同時にスキーママイグレーションを適用する：コードのロールバックが変更済みのスキーマに対して実行される必要がある場合、以前のバージョンのアプリケーションが壊れます。まず expand（追加）をデプロイし、どの旧バージョンもその列に依存しなくなってから、contract（削除）を行ってください。
• 外部 fork のプルリクエストで実行されるジョブから本番環境のシークレットにアクセスできる：外部 PR のコンテキストから、保護された環境のシークレットにアクセスできてはなりません。

検証

• パイプラインの lint／静的検証、安全なブランチでの完全な実行、および意図的な障害テスト（重要な step が失敗したときにパイプラインが実際に停止し、成果物を昇格しないこと）。
• プロジェクトでこれらのプラクティスを採用している場合は、成果物のダイジェスト、SBOM、署名／来歴（attestation）を確認します。
• 本番環境で初めて実行する前に、実際の環境を代表する環境でロールアウトとロールバックを一通りリハーサルします。プロバイダーの設定を読むだけで済ませないでください。
• 承認ゲート、ブランチ保護、プロバイダーで設定された権限を確認します（push 権限を持つユーザーが上書きできるワークフローファイルだけを確認するのでは不十分です）。
• これらの証拠なしに、パイプラインを「安全」と宣言したり、ロールアウトを「完了」と宣言したりしないでください。ログにエラーがないことは、サービスが正常である証拠にはなりません。

関連するスキル

• $specsfy-specialist-deploy がリリースとデプロイ全体を調整します。このスキルはパイプラインと昇格を担当します。
• $specsfy-specialist-versioning が SEMVER を準備し、成果物、変更履歴、タグ、昇格間でバージョン番号を一致させます。
• $specsfy-specialist-ansible がホストに冪等な設定を適用します。このスキルはデリバリーの昇格、承認、来歴を管理します。
• $specsfy-specialist-software-architecture が、パイプラインによって環境間で実現される境界と構造上の制約を定義します。
• $specsfy-specialist-observability が、ロールアウトを続行、一時停止、またはロールバックするかを判断する客観的なシグナル（エラー、レイテンシ、飽和度）を提供します。
• デプロイ先が Swarm クラスターの場合は $specsfy-specialist-docker-swarm を使用します。このスキルは昇格までのパイプラインを設計し、もう一方はクラスター内でロールアウトを実行します。
• $specsfy-specialist-application-security は、パイプラインの認証情報、サプライチェーン、成果物の署名を強化します。
• $specsfy-specialist-performance-engineering は、トラフィックを全面開放する前にロールアウトのパフォーマンスベースラインが必要な場合に使用します。
• プロジェクトがブランチ戦略として Gitflow を宣言している場合は $specsfy-specialist-gitflow を使用します。そちらのスキルは正しいブランチとタグ（release/*／hotfix/* から main へのマージ）を提供し、このスキルはパイプラインがそれらにどう反応するかを決定します。

パイプラインの最低限のステップ、リリース戦略とサプライチェーンの比較、および公式ソースについては、references/standards.md をお読みください。