Service Update 22R2 and Beyond Without Customizations

Apply a Service Update without Customizations - 22R2 & Beyond

Overview

When a new service update is released by IFS, and the user intends to apply it to their Build Place, the following steps must be followed if the customer's Build Place is classified as a Build Place Without Customizations. The user must initiate the service update operation following the steps outlined below. Once the operation is triggered, the selected service update will be fetched and applied to the Customer Baseline Repository first. After that, it will be applied to the Customer Solution Repository, and a sanity build will be executed to ensure there are no build errors.

How to Identify a Build Place without Customizations?

If the Customer Solution Repository of the master branch consists of only the mandatory files*, these customers are identified as customers who are not implementing any customizations or configurations within their Build Place. Hence, they will be taken through the shorter path of the Service Update process.

Note

• Mandatory files are version.txt, solutionset.yaml, and translationusage.json.

Steps to Apply Service update to Build Place

Follow the steps below to apply a service update to a Build Place

• Go to the Build Studio of the IFS Lifecycle Experience Center.
• Select the Build Place you wish to apply the service update.

• Click the Service Update in the Build Place view (Figure 1.1).

  Figure 1.1 - Service Update button in BuildPlace view

• The following dialog box appears after you click Service Update in Build Place.

  Figure 1.2 - Apply Service Update dialog for No customization users

• Select a later service update version that you intend to apply to the Build Place from the IFS Cloud Service Update Version drop-down list[1].

• The information panel [2] below the service update version shows the current version of the Build Place, and it reminds the user that once the operation is triggered, the service update will be applied to both Customer Baseline and Customer Solution repositories. Then, a Sanity Build will be triggered after that to ensure the service update is completed without build errors.

• Upon clicking the Next [3], a confirmation dialog box appears (Figure 1.3). It contains a warning message reminding that the Service Update and Sanity Build processes are about to start, and it takes several hours to complete. Also, it highlights that limited operations will be allowed during the operation.

  Figure 1.3 - Confirmation dialog of the no customization service update flow

• Click the checkbox [1] and click Confirm [2] to proceed with the Service Update. Also, the user has the option to terminate the process by clicking Cancel [3].

• The Confirm Service Update and Sanity Build process contains 3 consecutive operations. The first operation is to apply the Service Update to the Customer Baseline Repository, and the second operation is to apply the Service Update to the Customer Solution Repository, and finally, the Sanity Build operation.

• Upon clicking Confirm, the system will start the Service Update process with the first operation of applying the Service Update to the Customer Baseline Repository.

  Figure 1.4 - Apply Service Update to Customer Baseline is in-progress

• Once the Service Update is applied to the Customer Baseline Repository, the next step will begin without any user interaction, which is to apply the Service Update to the Customer Solution Repository.

  Figure 1.5 - Apply Service Update to Customer Solution is in-progress

• Finally, the system will start the Sanity Build operation.

• Job record details (Figure 1.6) of these operations can be viewed by clicking Jobs at the top main menu in the Build Place view.

  Figure 1.6 - No Customization Service update job records

• Once the entire process is completed, all Build Place users will see a success toast message, as shown below, when they navigate to the BuildPlace for the first time after the operation. This message indicates that the service update was successfully applied and the sanity build had completed without errors.

  Figure 1.7 - No customization service update operation success

Steps to follow when the Service Update Fails

The Service Update and Sanity Operations might encounter failures during the processes. Depending on the failure stage, the user may have to choose various actions as mentioned below.

1. The operation fails when applying the Service Update to the Customer Baseline Repository

   • Users will see an error toast message as below when they navigate to Build Place for the first time after the process failed.

   Figure 1.8 - Error toast on Service Update Fail when applying to the Baseline Repository

   • In such a case, the user can start over the process by selecting the same or a newer Service Update.

2. The operation fails when applying the Service Update to the Customer Solution Repository

   • Users will see an error toast message as below when they navigate to Build Place for the first time after the process failed.

   Figure 1.9 - Error toast on Service Update Fail when applying the Service Update to the Solution Repository

   • In such a case, the user has two options to proceed with their service update. When the user clicks Service Update again in the Build Place after the failure, the following dialog box will appear, containing two options.

   Figure 1.10 - Retry Service Update Options

   • Option 1: The user can start the process over with a new Service Update version. (This option will be disabled if there are no new service updates available)

   • Option 2: The user can attempt to reapply the same service update version, beginning from applying the Service Update to the Solution Repository phase onwards. Then, the Service Update applies to the Customer Solution Repository, and a Sanity Build triggers.

   • Additionally, the dialog box contains the option to run an impact analysis if the user intends to run an impact analysis.

3. The operation fails during the Sanity Build

   • The user will see an error pop-up message as below when navigating to the Build Place for the first time after the process has failed. (Figure 1.11)
   • In such a case, the user can retry the Sanity Build operation by clicking the Retry button available in the error pop-up message or close it by clicking Cancel.

   Figure 1.11 - Pop-Up Message on Service Update Process Fail during Sanity Build

   • Furthermore, the user can retry the Sanity Build process by selecting the latest commit from the BuildPlace's Sanity Build process. Read more on Sanity Builds