5.3.1 Preserving the customized Ops I features

This section explains the tasks required to upgrade Ops I while preserving Ops I features and incorporating the latest features added in the Ops I upgrade.

Users can edit customizable YAML definitions from Ops I to customize Ops I features. For details on customizable YAML files, see “Customizing the default YAML files”. For details on customizing the ticket window, see “Customizing the ticket window”. For details about customizing the workflow window, see “Customizing the workflow 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.
In addition, the following working branches are created during Ops I version upgrades:
  • opsi/Ops I new version-itsm
    Created when additions or changes are made to the base code for ITSM-related functions, such as ticket management.
  • opsi/Ops I new version-common
    Created when additions or changes are made to base code other than those described above.

Note that some working branches might not be created, depending on the functions added in the new version of Ops I.
If there are no conflicts between the base code changed in the new version and the user-customized code, the working branch is deleted when the base code is merged into the main branch.

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 the base code on the opsi/release branch.
3-1. Create a working branch, and commit the base code added in the new version.
3-2. Merge the changes from the working branch into the opsi/release branch.
3-3. If there are any "Merge requests" from the working branch to the main branch created during past upgrades that have not been merged, they will be closed.
3-4. Create a "Merge request" from the working branch to the main branch and execute it.
  • No conflict: The merge was successful, the base code of the new version is recognized as document, and the task is complete.
    When merged into the main branch, the working branch is deleted.
  • Conflict detected: The merge is interrupted, and a notification related to the conflict that occurred is sent to the user.
 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. Open unresolved "Merge requests" in the apps repository where a conflict occurred.
If multiple versions have been upgraded one after another, any conflicting "Merge requests" from earlier versions will be automatically closed.
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 GitOps 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


NotesNotes

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.


(1) Conflicts with customized workflow windows

Conflicts might occur if the customized workflow window is upgraded. After the upgrade, take the following actions according to the conflicting sections in the YAML file:

  • In columns not to be displayed:
    Incorporate the upgraded portions from Ops I. If the setting is not commented out, comment it out.
  • In columns to be displayed:
    Incorporate the upgraded portions from Ops I. If the setting is commented out, uncomment it.
  • Other sections:
    Incorporate the upgraded portions from Ops I.

For detailed instructions, see “Customizing the workflow window”.