Fetch the 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¶

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

Figure 2.2 - 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 2.3).

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

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.

Additional Warning Messages and Troubleshooting Steps¶

Upon receiving one of the warning messages listed below on the Apply Release Update Dialog (Figure 1.2), the user is required to follow the relevant troubleshooting steps mentioned under each section to move onto the latest versions of AKS cluster and/or Service Update in order to proceed with the Release Update process.

1. AKS Cluster Validation¶

If the AKS cluster version of a Buildplace created in the Cloud residency option is below 1.20.7, the following warning message is displayed:

'Middle tier (AKS cluster) of both Build Place and Use Place should be upgraded to 1.20.7 or above to start the release update process'

If the AKS cluster version of a Buildplace created in the Remote residency option is below 1.20.7, the following warning message is displayed:

'Middle tier (AKS cluster) of Build Place should be upgraded to 1.20.7 or above to start the release update process'

Troubelshooting Steps¶

At such an instance, it is required to contact IFS support to get the AKS cluster upgraded.

2. Service Update Validation¶

If the Service Update version of the customer solution repository is below 21.1.5 (21R1 track), the following warning message is displayed:

'IFS Cloud 21R1 SU5 or above should be applied in both Build place and Use Place prior to start the release update process'

Troubelshooting Steps¶

At such an instance, a newer service update can be fetched by following the steps listed in Applying Service Updates.