release-engineering

リリースエンジニアリング

コミットから顧客へのソフトウェア提供を、安全かつ予測可能に、迅速に実現するパイプライン、プロセス、アーティファクト、ゲート、コンプライアンス証跡、メトリクスを設計・運用する、シニアからプリンシパルレベルのリリースエンジニアリング手法です。

担当範囲

担当すること	担当しないこと
リリースプロセスの設計 — ブランチ戦略、プロセスモデル、リリース頻度	アプリケーション機能の実装 — backend-engineering／frontend-engineeringを参照してください
CD パイプラインのアーキテクチャ — 一度のビルドから昇格させるステージ、ゲート、成功時のプッシュ	本番環境のインシデントの根本原因のデバッグ — systematic-debuggingを参照してください
プログレッシブデリバリー — カナリア、リング、段階的ロールアウト、フィーチャーフラグ	オンコールと SLO の運用 — site-reliability-engineeringを参照してください
バージョン管理とアーティファクト — SemVer、Conventional Commits、変更履歴、不変性、来歴情報	セキュリティ実装と脅威モデリング — secure-software-engineeringを参照してください
リリース準備状況と品質ゲート — リリース候補、実施可否の判断、承認	内部開発者プラットフォームの構築 — platform-engineeringを参照してください
ロールバックと復旧計画 — ランブック、リハーサル、復旧目標	データパイプラインの運用とスキーマ移行のエンジニアリング — data-engineeringを参照してください
変更ガバナンスと監査コンプライアンス — SOC 2／SOX／PCI の証跡チェーン	仕様の作成と SDD ゲートの仕組み — spec-driven-developmentを参照してください
DORA メトリクス — 定義、算出、しきい値	API コントラクトの設計とバージョニングポリシー — api-design-and-evolutionを参照してください
複数チーム間のリリース調整 — リリーストレイン、カレンダー、安定化	明示的な基準に基づく証跡の収集と判定 — verification-methodologyを参照してください
リリース運用 — ブランチの切り出し、パイプラインのトリアージ、緊急リリース	ランタイムのモニタリングとアラート — これは SRE の担当です

基本原則

一度ビルドし、何度も昇格させます。 すべてのゲートを通過したアーティファクトだけをリリースします。環境ごとに再ビルドするとリスクが再び持ち込まれ、検証済みの内容が無効になります。

小さなバッチは、より速く、より安全にリリースできます。 トランクベース開発による頻繁な小規模マージは、デプロイ頻度、リードタイム、変更失敗率、復旧時間のすべての DORA メトリクスで、長期間存続するブランチを上回ります。

デプロイとリリースを切り離します。 コードを本番環境にデプロイすることと、ユーザーに公開することは同じではありません。フィーチャーフラグと段階的ロールアウトで両者を分離すれば、それぞれ異なるタイムラインで実施でき、個別に元に戻せます。

自動化された安全対策は、承認の官僚主義に勝ります。 証拠に基づく制御とパイプラインゲートは、変更諮問委員会による承認よりも優れています。調査によると、変更諮問委員会による承認は、デリバリーを遅くし、安定性を損なう傾向があります。チェックは自動化し、人による承認は本当に例外的な変更に限ります。

ロールバックをリハーサルします。 練習していないロールバックは、切迫した状況で失敗します。ロールバックは、専用のランブック、トリガーのしきい値、リハーサル記録を備えた、第一級のリリースアーティファクトです。

本番環境で検証します。 ステージング環境との同等性は役立ちますが、準備状況が実際に証明されるのは、本番環境のカナリア、スモークテスト、可観測性ゲートです。実際のトラフィック、実際のテレメトリー、実際の判断ポイントが重要です。

サプライチェーンを保護します。 すべてのアーティファクトに署名し、来歴情報と SBOM データを記録して、レジストリをセキュリティ境界として扱います。完全性はリリースの一部であり、後付けではありません。

DORA はシステム全体の成果です。 速度と安定性は、バッチサイズ、アーキテクチャ、自動化、安全性を重視する文化といったプロセスの設計によって生まれるものであり、メトリクスの目標値を追いかけて得られるものではありません。

読み込みガイド

ファイル	読み込むタイミング
references/role-and-career.md	リリースエンジニアの役割を理解するとき — 組織内での位置づけ、日々の業務、シニア／スタッフ／プリンシパルのレベル、各レベルを分ける根拠
references/skills-competency-model.md	リリースエンジニアが習得する技術スキルと専門スキル、およびシニア以上で差を生むスキルを整理するとき
references/release-process-models.md	プロセスモデルを選ぶとき — トランクベース、GitFlow、GitHub Flow、リリースブランチ、リリーストレイン、および組織に合ったリリース頻度
references/cd-and-pipeline-stages.md	CD パイプラインを設計するとき — 一度だけビルドして昇格させる方法、ステージゲート、成功時のプッシュ、パイプラインのコード化、環境に依存しないビルド、環境間の一貫性
references/progressive-delivery.md	カナリア、ブルー／グリーン、リング、パーセンテージによるロールアウト、メトリクスとエラーバジェットのゲート、自動ロールバックのトリガーを計画するとき
references/change-governance-and-compliance.md	監査対応可能な変更管理を構築するとき — SOC 2 CC8.1、SOX ITGC、PCI の切り戻し、エビデンスチェーン、職務分掌、緊急変更
references/readiness-and-quality-gates.md	リリース準備の各項目、リリース候補、Go／No-Go の構成、エラーバジェットに基づくリリースポリシー、完了の定義を定めるとき
references/rollback-and-recovery.md	システムの種類ごとにロールバック、ロールフォワード、フラグによる復旧を計画するとき — リハーサル済みのロールバック、時間制限付きの判断、隔離
references/versioning-and-artifacts.md	SemVer／CalVer ポリシー、Conventional Commits、変更履歴の規約、アーティファクトの不変性と来歴を設定するとき
references/feature-flag-lifecycle.md	フラグのライフサイクル全体（作成、保護、ロールアウト、検証、削除、期限切れ）を管理し、フラグの負債を避けるとき
references/monorepo-polyrepo-release.md	モノレポとポリレポのリリース戦略、影響を受けるビルドの検出、トポロジカルな公開順序、リリースツールを選ぶとき
references/toolchain-landscape.md	カテゴリ別にツールを選ぶとき — CI/CD、リリース自動化、アーティファクトリポジトリ、GitOps、フィーチャーフラグ（2025～2026 年の状況）
references/supply-chain-security.md	サプライチェーンを強化するとき — SLSA、SBOM、sigstore による鍵なし署名、依存関係の更新、来歴の証明
references/metrics-and-dora.md	5 つの DORA メトリクス、そのしきい値、ベンダー間の差異、測定時の落とし穴を定義し、算出するとき
references/release-operations-and-triage.md	リリーストレインを最初から最後まで運用するとき — ブランチの作成、安定化、Go／No-Go、パイプラインのトリアージ、リリースインフラの信頼性、エージェントによる自動化
templates/release-plan.md	リリース計画を作成するとき — スコープ、マイルストーン、担当者、リスク、ロールアウト、ロールバック時の対応、コミュニケーション
templates/release-readiness-checklist.md	準備状況レビューを行うとき — 項目ごとに担当者とエビデンスを記録するチェックボックス表、Go／No-Go 欄
templates/rollback-runbook.md	ロールバック手順書を作成するとき — トリガー、レイヤーごとの手順、検証、順序、コミュニケーション、リハーサル記録
templates/release-notes.md	リリースノートを作成するとき — バージョン、日付、変更の種類ごとのセクション、破壊的変更、移行手順
templates/change-governance-record.md	監査対応可能な変更を記録するとき — チケット、PR、CI 実行、アーティファクトダイジェスト、デプロイ日時、検証、緊急フラグ
templates/hotfix-emergency-release-plan.md	緊急リリースを計画するとき — 重大度、緊急時の承認、迅速な手順、実施後のレビュー
assets/dora-metrics-reference.md	5 つの DORA メトリクスを 1 ページで確認するとき — 計算式、単位、データソース、しきい値、落とし穴
assets/versioning-decision-table.md	バージョン管理方式を選ぶとき — SemVer と CalVer、独立バージョンと単一バージョン、バージョン更新のルール
assets/deployment-strategy-matrix.md	デプロイ戦略を比較するとき — ローリング、ブルー／グリーン、カナリア、リング、フラグ、シャドウを速度、安全性、ロールバックで比較
assets/release-toolchain-cheatsheet.md	カテゴリ別にツールをすばやく確認するとき — 各ツールの概要と選ぶ場面
scripts/version_bump.py	Conventional Commits または git の範囲から次の SemVer を算出するとき
scripts/semver_check.py	厳密な SemVer バージョンを検証、比較、または並べ替えるとき
scripts/changelog_check.py	Keep a Changelog または Release Please 形式の CHANGELOG.md ファイルを検証するとき
scripts/dora_metrics.py	デプロイイベントとコミットイベントのデータから 5 つの DORA メトリクスを算出するとき
scripts/release_plan_scaffold.py	フラグまたは git の範囲からリリース計画ドキュメントのひな形を作成するとき
evals/evals.json	このスキルの出力品質評価を実行するとき（スキーマ v1、8 ケース）

関連スキル

• テスト戦略、回帰テストの範囲、フレークのポリシー、品質ゲートの意味を定義するには、qa-methodology を使用します。このスキルでは、その結果得られたエビデンスを運用面およびガバナンス面のエビデンスと組み合わせて、リリースの判断を行います。
• AI エージェントのリリースでは、行動、軌跡、モデルの回帰に関するエビデンスを設計・解釈してリリースゲートに組み込む前に、agent-evals-and-observability を使用します。

スクリプト

スクリプト	実行方法	目的
version_bump	python3 scripts/version_bump.py --current-version 1.4.0 --git-range v1.4.0..HEAD	Conventional Commits に基づいて次の SemVer を算出します。breaking → メジャー（0.x ではマイナー）、feat → マイナー、fix → パッチ。プレリリースタグは任意です
semver_check	python3 scripts/semver_check.py --check 1.2.3-beta.1	厳密な SemVer 2.0.0 を検証し、2 つのバージョンを比較するか、一覧を並べ替えます
changelog_check	`python3 scripts/changelog_check.py CHANGELOG.md [--format auto	keep-a-changelog
dora_metrics	python3 scripts/dora_metrics.py --events events.json	デプロイおよびコミットのイベントデータから、5 つすべての DORA メトリクスを算出します
release_plan_scaffold	python3 scripts/release_plan_scaffold.py --version 2.0.0 --owner alice --output plan.md	フラグまたは git の範囲からプレースホルダーを埋めて、リリース計画書のひな形を作成します

トリガー

次のタスクに関わる場合、このスキルを読み込みます。

• リリース計画 — リリース計画、タイムライン、マイルストーン、またはロールアウト戦略の策定
• パイプライン設計 — CD パイプライン、昇格ステージ、または push-on-green の設計やレビュー
• バージョン更新 — 次のバージョンの算出、SemVer の検証、Conventional Commit の分類
• 変更履歴 — 変更履歴の作成または検証
• 準備状況のレビュー — 実施可否の判断、リリース候補、準備状況チェックリスト
• ロールバック計画 — ロールバック手順書や復旧計画の作成、またはリハーサル
• 段階的デリバリー — カナリア、リング、段階的な割合でのロールアウト、トラフィックのシャドーイング
• 機能フラグ — フラグのロールアウト、ライフサイクル、クリーンアップ
• リリーストレイン — 定期リリース、ブランチの切り出し、安定化期間
• DORA メトリクス — 5 つの DORA メトリクスの定義、算出、報告
• コンプライアンスエビデンス — SOC 2 / SOX / PCI の変更記録、監査証跡、職務分掌
• アーティファクトとサプライチェーン — SBOM、来歴、署名、レジストリの衛生管理
• 緊急リリース — ホットフィックス、緊急変更、迅速なリリース経路
• 複数チームの調整 — チーム横断のリリースカレンダーと統合の安定化

使用しない場合

代わりに、指定された関連スキルを利用してください。

• backend-engineering / frontend-engineering — アプリケーション機能の実装。リリースエンジニアリングでは、コードをリリースするパイプラインを設計します。コード自体は実装しません。
• systematic-debugging — 本番環境のインシデントの根本原因分析、障害箇所の特定、バグの再現。リリースエンジニアリングでは復旧を計画し、デバッグでは原因を特定します。
• site-reliability-engineering — オンコール運用、SLO／エラーバジェット管理、キャパシティプランニング、日々のインシデント対応。
• secure-software-engineering — セキュリティの実装と脅威モデリング。リリースエンジニアリングではセキュリティ対策（SBOM、署名、依存関係のスキャン）を利用しますが、それらの設計は行いません。
• platform-engineering — CI インフラストラクチャ、GitOps コントローラー、セルフサービスツール、ゴールデンパスなど、社内の開発者プラットフォームの構築。
• data-engineering — データパイプラインの運用、スキーマ移行のエンジニアリング、データ品質の監視。
• spec-driven-development — 仕様の作成、SDD パイプラインのゲートと判定の実行。
• api-design-and-evolution — API コントラクトの設計とバージョニングポリシー。リリースエンジニアリングでは成果物のバージョンを更新しますが、API の進化に関するルールは定めません。
• verification-methodology — 明示された合格／不合格基準に照らして、証拠を収集し判定を下すこと。

停止条件と完了条件

• リリース計画の完了条件： 計画に、バージョン、目標日、マイルストーンとブランチカット、担当者（RACI）、対象項目、軽減策を含むリスク、ロールアウト計画、ロールバック時の対応、コミュニケーション計画、承認が記載されていること。
• 準備状況チェックリストの完了条件： 各領域（機能、非機能、運用、ガバナンス）のすべての項目に担当者と証拠があり、Go／No-Go の判断が記録されていること。
• ロールバック手順書の完了条件： トリガーのしきい値、影響評価、判断基準、レイヤーごとのロールバック手順、検証用 SLI、ロールバックの順序、コミュニケーション、リハーサルの記録がすべて整っていること。
• バージョン更新の完了条件： 実際のコミット履歴（または明示的なファイル）に基づいて次のバージョンを算出し、厳密な SemVer に照らして検証し、規約に沿ったコミットの種類に基づいて更新ルールを正当化していること。
• コンプライアンス記録の完了条件： 変更の流れ（チケット → PR レビュー → CI → 承認 → デプロイログ → 検証）が完了し、サンプリングされ、ポリシーに従って保持され、職務分掌が遵守されていること。
• エスカレーションの上限： 診断を3回行っても収束しない場合は停止し、ここまでに収集した証拠を報告してください。