Complete the Release Update Process

Overview

This section describes the cutover process of complete release update step in Release Update Studio.

Notes

• All active environments in both Release Update Studio and Build Place should be deleted prior to start this process.
• Other Build Place activities are not possible during this process. Thus, this step should be performed when the Build Place is not in use.
• Once the Build Place is fully updated to the new Release Update, customers will no longer have access to the previous release.

Behavior of the Release Update Studio Navigator

The final step of the Release Update process is the Complete Release Update and it can be performed by a user with technician user role. The following requirements should have fulfilled for the complete release update button to be visible.

• should logged into release update studio as a technician user role
• should have completed "Apply Release Update" - in Release Update summary table "Apply release update" step status should show as "completed"
• should exist at least one approved delivery created from release update studio

When the above requirements are fulfilled, the "Complete Release Update" button will be visible on the release update studio. (Figure 1.1).

Figure 1.1 - Navigator of the Release Update Studio

Trigger Complete Release Update from the Release Update Studio

Note: Following should be completed prior to trigger the Complete Release Update.

• The Release Update Deployment should be completed in use place environment(s).
• There should not be any service update operations in both Buildplace and Release Update Studio.
• There should not be any customization projects in Buildplace.

There could be three scenarios when doing a Complete Release Update;

• Scenario 1 - When there are no environments created and no deliveries created from the Buildplace detailed view page during the Release Update period
• Scenario 2 - When there are environments created from Buildplace or Release Update Studio
• Scenario 3 - When there are no environments available in the Buildplace but there are approved deliveries created from the Buildplace detailed view during the Release Update period

Scenario 1

When there are no environments created and no deliveries created from the Buildplace detail view, after applying the Release Update to the baseline repository, once the "Complete Release Update" button is clicked, a dialog box will be opened with the following information (Figure 1.2).

Figure 1.2 - Complete Release Update Dialog box - Scenario 1

1. A warning message to inform that the Buildplace will be frozen during the cutover

2. A note to educate the user on doing the cutover

3. A checkbox to confirm that the Release Update is deployed and tested in Use Place. The Complete button will be enabled only when the user checks this checkbox.

4. Clicking the Complete button prompts a confirmation pop-up box (Figure 1.2.1).

Figure 1.2.1 - Complete Release Update Confirmation

​

1. Clicking the Cancel button closes the dialog-box and navigates the user into the Release Update Studio

2. A warning text that informs user to do this during a non-production time

3. A text to inform user on the version user is going to cutover the Builplace to

4. Confirmation checkbox that the user needs to tick to reconfirm to perform the cutover

5. The "Confirm to Complete Now" button only gets enabled once the checkbox is ticked and by clicking user will be able to start the cutover process. It will prompt a feedback form so that user is able to provide the feedback regarding the overall experience in the release update process.

6. Clicking the Cancel button closes the prompted confirmation pop-up box and navigates back to the "Complete Release Update" dialog box.

Scenario 2

When there are environments created either from Buildplace detail view or from Release Update Studio, the dialog box will show a message indicating to delete all the environments and try again. In this scenario the "Complete" button will not be enabled until all the environments are deleted.

Figure 1.3 - Complete Release Update Dialog box - Scenario - 2

Once deleted the environments, user will be able to proceed with the Complete Release Update process.

Scenario 3

In this scenario, when there are approved deliveries available which were created from the Buildplace detailed view page during the Release Update period(after applying the release update to the baseline), the dialog box will show the following information other than the information shown in the scenario1.

Figure 1.4 - Complete Release Update Dialog box - Scenario - 3

1. Number of deliveries created from current track
2. A note that recommends user to reimplement the listed deliveries in release update branch as well, if they are already deployed in production or intended to apply in production
3. List of approved deliveries created from customer solution repository master branch
4. Confirmation checkbox that the user needs to check to confirm the reimplementation of the necessary deliveries. Both check boxes needs to be checked for the "Complete" button to be enabled.

Behavior while Buildplace Cutover is in progress

While the cutover is in progress which can take up to 30 - 60 minutes the Buildplace and Release Update studio will be unavailable for other operations and the following banner (Figure 1.7) will be shown to the user in the Builplace detail view and in the Release Update Studio.

Figure 1.7 - Cutover Banner

During the cutover, customer baseline repository master branch and customer solution repository master branch will be renamed as master-<current-version-of-master-branch> (eg: master-21.1.8). As a result of the cutover, the release update branches in customer baseline repository and customer solution repository which were created during the apply release update step, also will be renamed to master and those branches will become the default master branch in each repositories (Figure 1.8).

Figure 1.8 - Renamed branches during the cutover

During cutover process, all the Buildplace sanity tags including OK, FAILED, PENDING will be renamed from san-<timestamp>-<status> to <appversion>-sanity-<timestamp>-<status>. (eg: san-1629979204-OK to 21.1-sanity-1629979204-OK). All the sanity tags including OK, FAILED, PENDING tags created from Release Update Studio (eg: san-ru-16394747383-OK) will be renamed as san-<timestamp>-<status> (eg: san-ru-16394747383-OK to san-16394747383-OK).

Once the cutover had successfully completed, "Go to Release Studio" button which was available in Buildplace card view will be disappeared and the Buildplace card will appear as in the below image (Figure 1.9).

Figure 1.9 - Buildplace Card View after the cutover

Upon successful completion of cutover process, Buildplace detail view again becomes to not frozen state.When you go inside Buildplace detail view by clicking "Go to Buildplace" button, the versions of customer baseline and customer solution repositories shown in repository information will have been upgraded (Figure 1.10).

Figure 1.10 - Repository Information after the cutover

Now the Buildplace is in upgraded state and it is available to do the customizations again !!!.