構成管理とは、「いつ・どの環境に・何のコンポーネントの・どのバージョンが動いているか」を記録・追跡・管理する仕組みです。

本システムはKeycloak・PostgreSQL・OCP CLI Clientの3コンポーネントで構成されており、dev・多面・性能・検証・本番の5つの環境に順次リリースされます。環境が複数あるため、「どこに何が入っているか」を管理しないと以下のような問題が発生します。

環境ごとにバージョンがバラバラになり、「検証ではOKだったのに本番で動かない」が起きる

障害時に「何が原因か・どこに戻せばいいか」の特定に時間がかかる

新規メンバーが「今どういう状態か」を把握できない

なぜこのシステムで構成管理が必要か

本システムは認証認可を担うため、障害発生時の影響範囲が広く、迅速な原因特定と復旧が求められます。構成管理を徹底することで、障害時の対応速度を上げ、リリース時の環境差異によるトラブルを防ぎます。

本システムで管理対象とするものは以下の通りです。

以下は本構成管理の対象外です。

リリースは必ず以下の順序で進めます。

dev・多面 → 性能 → 検証 → 本番

問題を早い段階で発見し、本番への影響を防ぐ

ためです。開発環境で発見できた問題ほど、修正コストが低く影響範囲も限定されます。順序を飛ばして本番に適用することは原則禁止です。

「商用環境には何が入っているか」を常に把握する重要性

商用環境（性能・検証・本番）は、それぞれ異なるタイミングで更新されるため、環境ごとに入っているバージョンが異なる状態が常態です。

例えば以下のような状態が発生します。

この状態を把握していないと、障害発生時に「どの環境で何が動いているか」の確認から始めることになり、復旧が遅れます。環境別のデプロイ状況は常に最新の状態に更新してください。（→ 2.3 環境別デプロイ状況の管理）

コンポーネントのバージョンアップ・設定変更・マニフェストの修正など、いかなる変更もdev環境への適用から始めます。

dev環境で問題がないことを確認してから次の環境に進んでください。

商用環境への変更は承認フローを経る

商用環境（性能・検証・本番）への変更は、作業者が単独で判断して進めることはできません。以下の承認フローに従ってください。

変更内容の起票 → レビュー・承認 → 作業実施 → 結果報告

承認なしで商用環境に変更を加えた場合、障害発生時の原因特定が困難になるだけでなく、チーム全体が「今どういう状態か」を把握できなくなります。

変更を実施したら、以下の内容を必ず記録してください。

記録がないと、障害発生時に「いつ・何が変わったか」を追跡できず、原因特定と復旧に時間がかかります。

本ページで説明した構成管理の考え方を実際の運用に落とし込んだ手順・台帳は以下のページを参照してください。

これで「2.1 構成管理の考え方」ページの全セクションが揃いました。

全体を振り返ると以下の流れになっています。

なぜやるか（1章）
　↓
何を管理するか（2章）
　↓
環境とバージョンの関係（3章）
　↓
変更時のルール（4章）
　↓
詳細は各ページへ（5章）

新規メンバーがこのページを読めば「このシステムの構成管理の全体像」が掴めるページになったと思います。

構成管理について

1アプリにおけるドキュメント構成

1アプリにおけるドキュメント構成