OAK テストと統合オーナーシップ
概要
この ADR は、OAK（Omnibus-Adjacent Kubernetes）が複数の高度なコンポーネントをサポートするように拡張していく中でのテスト責任と統合オーナーシップモデルを定義します。Omnibus OAK コア機能と高度なコンポーネント統合の間に明確な境界を確立し、破壊的変更を防止してメンテナビリティを確保します。
問題の定義
OAK が複数の高度なコンポーネント（OpenBao、将来のコンポーネント）をサポートするように成長するにつれ、それぞれが異なるプロダクトチームによって管理される場合、以下のリスクがあります:
- 統合のドリフト: 高度なコンポーネントの Helm チャートまたは設定が変更されると、誰も気づかずに Omnibus オートメーションが古くなる可能性があります。
- 不明確なオーナーシップ: コンポーネントが変更された際に Omnibus を更新する責任が誰にあるか不明確です。
- テストのギャップ: コンポーネント統合が OAK のアップデートをまたいで機能し続けることを確保するための明確なプロセスがありません。
- メンテナンス負担: Omnibus チームはすべてのコンポーネント統合をリアルにテスト・維持することができません。
決定事項
私たちは以下のような分散責任モデルを確立します:
Operate チームの責任（初期実装）
- Operate チームは OAK の最初のイテレーションに責任を持ちます:
- OAK パターンの定義: NGINX 設定生成、Helm values 生成、PostgreSQL/Redis ネットワーク公開のパターンを確立する
- OpenBao 統合の実装: 最初の高度なコンポーネントとして OpenBao でパターンを実証する
- 統合フレームワークの作成: Omnibus がコンポーネント固有の Helm values と NGINX 設定を生成するためのメカニズムを構築する
- パターンのドキュメント化: 将来のコンポーネントに必要なパターンと期待事項を文書化する
- OAK コア CI/CD パイプライン: OAK コア機能の自動テスト
- 破壊的変更: Omnibus コアフレームワークの変更によって開始された場合、Operate チームはコンポーネントプロジェクトと Omnibus の両方で廃止予告と破壊的変更プロセス全体のオーナーシップを持ちます。プロダクトチームがプロセスをサポートする場合がありますが、Operate チームが調整します。
- Operate チームは Omnibus が設定・オートメーションするパターンを定義する責任を持ちます。
- Operate チームが（ベータ後に）オーナーシップを持たないもの:
- 個々のコンポーネント統合のメンテナンス
- コンポーネント固有の Helm チャートの検証
- コンポーネント固有の設定の詳細
高度なコンポーネントプロダクトチームの責任（将来のコンポーネント）
- 各プロダクトチームは高度なコンポーネントを管理するために以下のオーナーシップを持ちます:
- Helm チャートのメンテナンス: コンポーネントの Helm チャートを維持し、OAK パターンとの互換性を確保する
- Omnibus 統合の更新: Helm チャート構造が変更された際に Omnibus オートメーションを更新する
- 統合テスト: コンポーネントが OAK 生成の values で機能することを確認するテスト
- 設定ドキュメント: 期待される値と破壊的変更を文書化する
- 破壊的変更: チャートの変更によって開始された場合、プロダクトチームはコンポーネントプロジェクトと Omnibus の両方で廃止予告と破壊的変更プロセス全体のオーナーシップを持ちます。Operate チームがプロセスをサポートする場合がありますが、プロダクトチームが調整します。
- Omnibus 変更の実装: Helm チャート構造が変更された場合
- プロダクトチームがオーナーシップを持たないもの:
- OAK コアパターンとフレームワーク
- 他のコンポーネントのための Omnibus オートメーション
