5.3.1 Preserving the customized ticket function
This section explains the tasks required to upgrade Ops I while preserving customized ticket functions and incorporating the latest features added in the Ops I upgrade.
Users can edit customizable YAML definitions from Ops I to customize the ticket window. For details on customizable YAML files, see “Customizing the default YAML files”. For details on customizing the ticket window, see “Customizing the ticket window”.
The GitLab where the Ops I code is stored has the following branches.
- main branch: Branch recognized as document by Ops I
Users commit custom code. - opsi/release branch: Branch where the default YAML files provided by the Ops I service are stored
Ops I version upgrades are reflected.
Perform the following actions when upgrading.
(Table) Flow during version upgrade
| Task period | Task | Worker |
|---|---|---|
| Before upgrading | 1. When deploying for the first time, the opsi/release branch is created from the commit at the time of deployment. (If the version prior to the upgrade is v02-70 or later) |
Ops I provider |
2. Customize the code in the main branch and commit. |
User | |
| When upgrading |
3. Upgrade Ops I on the opsi/release branch.
When deploying v02-50, the opsi/release branch is created from the commit at the time of deployment. (If the version prior to the upgrade is v02-50) 3-1. Commit the base code added in the new version to the opsi/release branch.
3-2. Create a "Merge request" from the opsi/release branch to the main branch and execute it.
|
Ops I provider |
| After upgrading | 4. If there are conflicts, users must resolve them themselves and perform the merge.
4-1. Users belonging to the Ops I System Engineers group receive notifications regarding conflicts that occur during version upgrades via the Ops I GUI notification function.
4-2. Open "Ops I System Engineers" in GitLab.
4-3. In the apps repository, open the "Merge request" that caused the conflict.
4-4. Perform a commit to resolve conflicts in GitLab or in your local environment.
4-5. Merge.
4-6. Check that the YAML file has been successfully manipulated in the GitOps Log tab. For details on the GitOps Log tab, see "GitOps log tab".
The following "failed" results may appear in the operation log, but this is not a problem.
kind: system name: conf result: failed reason: format_error detail.message: "Validator for kind 'system', apiVersion '1.0' does not exists." |
User |
5. Next, commit the customized code to the main branch and manipulate it according to the user's objective. |
User |
Notes
- Users belonging to the Ops I System Engineers group are notified if a conflict occurs between the upgraded part of Ops I and the customized part of the default YAML files. Be sure to check and resolve any conflicts.