構成管理

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

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

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

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

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

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

2. 管理対象の定義

何を管理するか

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

管理対象	具体例
コンポーネントのバージョン	Keycloak 23.0.1 / PostgreSQL 15.3 / OCP CLI Client 4.14
マニフェスト（YAMLファイル）	デプロイ設定・Service・Route等の定義ファイル
Jenkinsパイプライン設定	各環境向けのジョブ設定・スクリプト
環境別のデプロイ状況	どの環境に何のバージョンが入っているかの記録
変更履歴	いつ・誰が・何を・どの環境に適用したかの記録

何を管理対象外とするか

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

対象外	理由
Keycloak上のレルム・クライアント設定	アプリ側の設定として別途管理
PostgreSQLのデータ（レコード）	データ管理として別途管理
OpenShiftプラットフォーム自体のバージョン	インフラチームが管理

3. 環境とバージョンの考え方

5つの環境の役割

区分	環境	役割
開発環境	dev	開発チームの主な作業環境。新機能・修正の開発はここから始める
開発環境	多面	複数チームが並行して利用できる環境。他チームへの動作確認依頼などに使用
商用環境	性能	性能試験を実施する環境。本番相当の負荷をかけて検証する
商用環境	検証	本番リリース前の最終確認環境。ここでOKが出て初めて本番に進める
商用環境	本番	実稼働環境。エンドユーザーが実際に使用する

環境を流れる順序と意味

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

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

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

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

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

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

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

4. 変更管理の原則

変更は必ずdev環境から始める

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

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

やること	やってはいけないこと
dev環境で動作確認後、多面→性能→検証→本番の順に進める	検証環境や本番環境に直接変更を適用する
各環境での確認が取れてから次の環境に進む	「たぶん大丈夫」で次の環境に進む

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

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

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

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

変更履歴を必ず残す

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

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

5. 関連ページ

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

ページ	内容
2.2 コンポーネントバージョン対応表	Keycloak・PostgreSQL・OCP CLI Clientの動作確認済みバージョンの組み合わせ一覧
2.3 環境別デプロイ状況の管理	各環境に現在何のバージョンが入っているかの記録台帳
2.4 マニフェスト（YAML）管理	YAMLファイルの構成・命名規則・Gitブランチ運用方針
5.1 リリースフロー概要	dev→多面→性能→検証→本番のリリース手順の全体像
6.1 ロールバックの判断基準	障害発生時にロールバックを判断する基準と手順

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

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

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

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

目次