Apply Release Update to Customer Baseline Repository¶

Overview¶

This section describes 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 Applying 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 3.1).


Figure 3.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.

Applying the Release Update to the Customer Baseline Repository¶

22R2 and Beyond¶

Steps of applying the Release Update to the Customer Baseline Repository¶


Figure 3.2 - Apply Release Update dialog box

Make sure to run impact assessment prior to applying Release Update to baseline repository as mentioned in the warning-type message [1] (Figure 3.2).
Select the delivery tag from the Delivery Tags dropdown [2] (Figure 3.2). The Delivery Tags dropdown will list all the approved deliveries related to the current product version of the Build Place in 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.

Note

It is not recommended to select a delivery created for a Recreate Build Home as the baseline delivery in a Release Update process.
The latest Service Update for the release is selected in the Request Release Update step and will be shown in the read-only text field [3] (Figure 3.2).
It is possible to change the service update, if required, by clicking the Change Service Update button [4]. This will list the latest 3 (or less) service updates that can be applied with the release update.
The following image shows how the user can switch between Service Updates using the Target Service Update dropdown to apply the Release Update in the Baseline repository (Figure 3.3).


Figure 3.3 - Changing Target Service Update

Once both parameters are selected, the "Apply" button [5] shall be clicked to trigger the release update pipeline (Figure 3.2).
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 3.2).

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

The solution set will be fetched from IFS Biz and it will be stored in the relevant storage account in Azure.
Central Build Services (CBS) will then migrate the Build Place related settings to its corresponding Release Update Studio.
CBS will create parallel repository branches in the Azure devops project and will set branch policies to release-update branch.
CBS will then remove all core code except version.txt file from release-update branch.
version.txt file will be updated to the new version in customer-baseline repository release-update branch.
CBS will finally fetch the solution set from the Azure storage account, commit to the customer-baseline repository and run the Baseline Build.
This will result in the 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.

Before 22R2¶

Steps of applying the release update to the Customer Baseline Repository¶

Select the delivery tag from the Delivery Tags dropdown [2].
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.
The latest Service Update for the release selected in the Request Release Update step will be shown in the read-only text field [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 3.2).


Figure 3.4 - Change Target Service Update

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 3.5).


Figure 3.5 - Apply Release Update dialog box

Once both parameters are selected, the "Apply" button can be clicked to trigger the release update pipeline.
If the decision is made not to proceed with the upgrade at this point, the "Cancel" button can be clicked to terminate the process.

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

The solution set will be fetched from IFS Biz and it will be stored in the relevant storage account in Azure.
Central Build Services (CBS) will then migrate the Build Place related settings to its corresponding Release Update Studio.
CBS will create parallel repository branches in the Azure devops project and will set branch policies to release-update branch.
CBS will then pull the selected release update from the master repository to the release-update branch in the baseline repository.
CBS will finally fetch the solution set from the Azure storage account, commit to the baseline repository and run the Baseline Build.
This will result in creating the release-update branch in the baseline repository with the new release update and the solution set and the release-update branch in the solution repository created from an approved delivery tag.