5.3.1 カスタムしたOps Iの機能の維持
Ops Iバージョンアップ時に、カスタムしたOps Iの機能を維持したまま、Ops Iバージョンアップにより追加された最新機能を取り込むために必要な作業を説明します。
ユーザーは、Ops Iからカスタム可能なマニフェストを編集し、Ops Iの機能をカスタムすることができます。カスタムが可能なマニフェストファイルについては「初期マニフェストファイルのカスタム」、チケット画面のカスタムについては「チケット画面のカスタム」を、ワークフロー画面のカスタムについては「ワークフロー画面のカスタム」を参照してください。
Ops Iのコードが格納されているGitLabには以下のブランチが準備されています。
- mainブランチ：Ops Iがドキュメントとして認識するブランチ
ユーザーがカスタムコードをコミットします。 - opsi/releaseブランチ：Ops Iサービス側が提供する初期マニフェストファイルが格納されるブランチ
Ops Iのバージョンアップが反映されます。
- opsi/Ops Iの新バージョン-itsm
チケット管理などITSMに関連する機能の基盤コードに追加・変更がある場合に作成されます。 - opsi/Ops Iの新バージョン-common
上記以外の基盤コードの追加・変更がある場合に作成されます。
なお、Ops Iの新バージョンで追加された機能によっては、一部の作業ブランチは作成されないことがあります。
新バージョンで変更された基盤コードとユーザーがカスタムしたコード間で競合が発生していない場合、mainブランチに基盤コードがマージされたときに、作業ブランチが削除されます。
以下の流れでバージョンアップ時の対応をしてください。
| 作業時期 | 作業 | 作業者 |
|---|---|---|
| バージョンアップ前 | 1. 新規デプロイ時に、デプロイ時のコミットからopsi/releaseブランチが作成されます。（バージョンアップ前のバージョンがv02-70以降の場合） |
Ops I提供者 |
2. mainブランチのコードをカスタムし、コミットします。 |
ユーザー | |
| バージョンアップ時 |
3. opsi/releaseブランチの基盤コードをバージョンアップします。
3-1. 作業ブランチを作成し、新バージョンで追加された基盤コードをコミットします。
3-2. 作業ブランチの変更内容をopsi/releaseブランチにマージします。
3-3. 過去のバージョンアップ時に作成された作業ブランチからmainブランチへの「Merge request」でマージされていないものがある場合、クローズします。
3-4. 作業ブランチから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上またはローカル環境で、競合を解消するコミットを行います。
GitLab上での競合解消については、「https://archives.docs.gitlab.com/19.0/user/project/merge_requests/conflicts/」を参照してください。 ローカル環境での競合解消については「ローカル環境での競合解消手順」を参照してください。 4-5. マージします。
4-6. GitOpsログタブで正しくマニフェストファイルの操作が成功していることを確認します。GitOpsログタブの詳細については「GitOpsログタブ」を参照してください。
GitOpsログに以下の「failed」の結果が表示される場合がありますが、問題ありません。
Kind: system Name: conf Result: failed Reason: format_error Detailのmessageの値: "kind 'system'、apiVersion '1.0' のバリデーターが存在しません。" |
ユーザー |
5. さらにmainブランチにカスタムしたコードをコミットし、ユーザーの目的に合わせて運用します。 |
ユーザー |
注意事項
- Ops Iのバージョンアップした部分と初期マニフェストファイルがカスタムされている部分の間で競合が発生した場合、Ops I System Engineersグループに属すユーザーに通知されます。必ず確認し競合を解消してください。
- 「opsi/」から始まるブランチに対して「rebase」のようなコミット履歴を書き換えるような操作は禁止されています。競合をローカル環境で解消する際は、「ローカル環境での競合解消手順」を参照してください。
ローカル環境での競合を解消するために、Gitを使用して対象リポジトリをローカル環境にクローンし、そのディレクトリへ移動します。リポジトリのクローン手順は「マニフェストファイルのGitLab登録方法（CUI」を参照してください。
競合解消の手順を以下に示します。
- リモートリポジトリの最新の状態を取得します。
git fetch
- 作業ブランチにチェックアウトします。
git switch 作業ブランチ名
- mainブランチを作業ブランチにマージします。
git merge origin/main
- すべての競合を解消するまで以下の操作を繰り返します。
- エディターで競合を解消します。
- 変更をステージングします。
git add .
- マージ処理を続行します。
git merge --continue
メモ
競合の解消中にマージ処理を中断し、作業ブランチをマージ実行前の状態に戻す場合は、以下を実行してください。git merge --abort
- 変更を作業ブランチへプッシュします。
git push origin 作業ブランチ名
（1）ワークフロー画面のカスタムの競合
ワークフロー画面をカスタムした状態でバージョンアップすると、競合が発生する場合があります。バージョンアップ後に、マニフェストファイル内のコンフリクトした箇所に応じて、次のように対応してください。
- 表示させないカラム内：
Ops Iのバージョンアップした部分を取り込みます。コメントアウトされていない場合はコメントアウトします。 - 表示させるカラム内：
Ops Iのバージョンアップした部分を取り込みます。コメントアウトされている場合はアンコメントします。 - その他の箇所：
Ops Iのバージョンアップした部分を取り込みます。
詳細の手順については、「ワークフロー画面のカスタム」を参照してください。