5.3.1 カスタムしたOps Iの機能の維持
Ops Iバージョンアップ時に、カスタムしたOps Iの機能を維持したまま、Ops Iバージョンアップにより追加された最新機能を取り込むために必要な作業を説明します。
ユーザーは、Ops Iからカスタム可能なYAML定義を編集し、Ops Iの機能をカスタムすることができます。カスタムが可能なYAMLファイルについては「初期YAMLファイルのカスタム」、チケット画面のカスタムについては「チケット画面のカスタム」を参照してください。
Ops Iのコードが格納されているGitLabには以下のブランチが準備されています。
- mainブランチ：Ops Iがドキュメントとして認識するブランチ
ユーザーがカスタムコードをコミットします。 - opsi/releaseブランチ：Ops Iサービス側が提供する初期YAMLファイルが格納されるブランチ
Ops Iのバージョンアップが反映されます。
以下の流れでバージョンアップ時の対応をしてください。
| 作業時期 | 作業 | 作業者 |
|---|---|---|
| バージョンアップ前 | 1. 新規デプロイ時に、デプロイ時のコミットからopsi/releaseブランチが作成されます。（バージョンアップ前のバージョンがv02-70以降の場合） |
Ops I提供者 |
2. mainブランチのコードをカスタムし、コミットします。 |
ユーザー | |
| バージョンアップ時 |
3. opsi/releaseブランチのOps Iをバージョンアップします。
v02-50デプロイ時のコミットからopsi/releaseブランチが作成されます。（バージョンアップ前のバージョンがv02-50の場合） 3-1. opsi/releaseブランチに、新バージョンで追加された基盤コードをコミットします。
3-2. 過去のバージョンアップ時に作成されたopsi/releaseブランチからmainブランチへの「Merge request」でマージされていないものがある場合、クローズします。
3-3. opsi/releaseブランチからmainブランチに、「Merge request」を作成し、マージを実行します。
|
Ops I提供者 |
| バージョンアップ後 | 4. 競合がある場合はユーザー自身で競合を解消し、マージを行います。
4-1. Ops I System Engineersグループに所属するユーザーは、Ops IのGUI通知機能でバージョンアップ時の競合発生に関する通知を受け取ります。
4-2. GitLabの「Ops I System Engineers」を開きます。
4-3. appsリポジトリ上の、競合が発生したクローズされていない「Merge request」を開きます。
複数のバージョンに対してバージョンアップを連続して行った場合、先行するバージョンで競合が発生した「Merge request」は自動でクローズされます。 4-4. GitLab上またはローカル環境で、競合を解消するコミットを行います。
4-5. マージします。
4-6. GitOpsログタブで正しくYAMLファイルの操作が成功していることを確認します。GitOpsログタブの詳細については「GitOpsログタブ」を参照してください。
操作ログに以下の「failed」の結果が表示される場合がありますが、問題ありません。
kind: system name: conf result: failed reason: format_error detail.message: "kind 'system'、apiVersion '1.0' のバリデーターが存在しません。" |
ユーザー |
5. さらにmainブランチにカスタムしたコードをコミットし、ユーザーの目的に合わせて運用します。 |
ユーザー |
注意事項
Ops Iのバージョンアップした部分と初期YAMLファイルがカスタムされている部分の間で競合が発生した場合、Ops I System Engineersグループに属すユーザーに通知されます。必ず確認し競合を解消してください。