Skip to content

Apply Release Update to Customer Baseline Repository

Overview

This section describe the process of fetching the Release Update to the customer-baseline repository from the Release Update Studio.

Prerequisites

  • Request Release Update step is completed.
  • Deliveries created from the current Service Update release version should exist.

Important Things to Consider Before Apply a Release Update

It is highly recommended to minimize customizations during the release update process due to the following reasons:

  • Available environment quota will be shared between both the build place and release update studio. So, ordering environments to test the customizations will reduce the environment quota available for release-update related steps.
  • If customizations are done after conducting an impact assessment or an impact analysis, the analysis needs to be conducted again to identify the impact accurately.
  • Changes done in the master branch needs to be re-done in the release-update branch and re-tested, cause a re-work for the users.
  • If the same file is changed in both master and release-update branches, there could be conflicts in the files.

Behavior of the Release Update Studio Navigator

The Release Update Studio navigator will display the two buttons; “Impact assessment” and “Apply Release Update in Baseline Repo” at the initial landing on the Release Update Studio homepage (Figure 1.1).

Figure 1.1 - Navigator of the Release Update Studio

To apply the Release Update to the customer baseline repository, the "Apply Release Update in Baseline Repo" button on the navigator needs to be clicked.

Trigger Apply Release Update in the Baseline Repository in the Release Update Studio
Figure 2.1 - Apply Release Update dialog box

The dialog box will display a warning-type message that recommends to minimize customizations during the release update process as the environment quota is shared between both the build place and release update studio [1].

Steps to fetch the Release Update to the Customer Baseline Repository

  1. Select the delivery tag from the Delivery Tags dropdown [2] (Figure 2.1).

    The Delivery Tags dropdown will list down all the approved deliveries related to the current App version in the descending order. The last approved delivery will be listed on top and will be selected by default. The delivery selected from this dropdown, will be used to create the release-update branch when fetching the release update to the Customer Baseline Repository. It is recommended to select the delivery tag related to the latest delivery deployed to the production environment of the use place. The reason for this recommendation is due to the fact that the latest approved delivery may not always be deployed to the production environment, it may still be in the testing stage in one of the non-production environments.

  2. The latest Service Update for the release selected in the Request Release Update step will be shown in the read-only text field [3] (Figure 2.1).

  3. Upon clicking on the "Change Service Update" button [4], button gets disabled and "Target Service Update" text field [3] turns to a drop-down field by giving the possibility to select any service update released under the requested release version(Figure 2.1).

    Following image shows how the user can switch between service updates to select the "Target Service Update" to apply release update in the Baseline repository(Figure 2.2).

    4-change_target_su
    Figure 2.2 - Changing Target Service Update

  4. If the target service update was changed, a warning-type message will be shown below the "Target Service Update" field recommending to run the Impact Assessment prior to proceeding with the selected Service Update (Figure 2.3).

    5-changed_target_su
    Figure 2.3 - Changed Target Service Update

  5. Once both parameters are selected, the "Apply" button [5] shall be clicked to trigger the release update pipeline (Figure 2.1).

  6. If the decision is made not to proceed with the upgrade at this point, the "Cancel" button [6] shall be clicked to terminate the process (Figure 2.1).

Backend processes of fetching the Release Update to the Customer Baseline Repository

  1. The solution set will be fetched from IFS Biz and it will be stored in the relevant storage account in Azure.
  2. Central Build Services (CBS) will then migrate the Build Place related settings to its corresponding Release Update Studio.
  3. CBS will create parallel repository branches in the Azure devops project and will set branch policies to release-update branch.
  4. CBS will then remove all core code except version.txt file from release-update branch.
  5. version.txt file will be updated to the new version in customer-baseline repository release-update branch.
  6. CBS will finally fetch the solution set from the Azure storage account, commit to the customer-baseline repository and run the Baseline Build.
  7. This will result in following outcomes:
    1. Creating the release-update branch in the customer-baseline repository with the new release update and the solution set.
    2. Creating the release-update branch in the customer-solution repository from an approved delivery tag.
    3. Removing all core code (except the version.txt file) from release-update branches in both customer-baseline and customer-solution repositories.