Taking a Release Update to a Build Place With Customizations

Introduction

The infographic below depicts the business process of Release Update Studio.

Note: Right click on the image and select Open image in new tab for a clearer view of the infographic.

The Release Update Process is applicable for customers who are on IFS Cloud 21R1 or above. The customers who use previous versions should first upgrade to IFS Cloud and continue to follow the Release Update process thereafter.

The user is expected to check whether adequate Build Place environments and user counts are in place. It should be noted that environments and users will be shared between Build Place and Release Update Studio during the Release Update process. Thus, it is highly recommended to increase such resources before the Release Update Process.

Note

It is highly recommended to freeze Build Place related activities (projects) during the Release Update process.

Getting Started

The users can log in to Release Update Studio by clicking the Release Available button on the My Build Places page, as shown below.

Upon navigating to the Release Update Studio, user can view four main components as described below;

The top layer would indicate the steps that should be followed in the Release Update process. When a current action is completed, the next possible action will be enabled.

The second layer would show the customer and repository information.

The third section will provide a snapshot of the current status of the Release Update process. This functionality makes collaboration easy where any user who logs in to the Release Update Studio is able to grasp the current status of the ongoing Release Update.

Before 22R2

The following is the Release Update Summary table for a customer with their product in a version prior to 22R2.

22R2 and Beyond

The following is the summary table for a customer who has their product in the 22R2 version or a version beyond that. These users can view Apply Release Update in Baseline Repo, Customization Upliftment Preparation, Apply Release Update in Solution Repo statuses in the summary table.

The fourth section of the screen has information on environments. The user has the option of ordering environments similar to the Build Place and the environments ordered via Release Update Studio are labeled as created for RU for easy reference.

User Journey

1. Conduct Impact Assessment

   Note: This step can be skipped if there are no customizations present.

   The objective here is to obtain a high-level understanding of the impact due to current customizations. Please note that user should have installed Update Analyzer tool prior to run this process. The tool is freely available on the developer.ifs.com site. Refer detail documentation - Impact Assessment

2. Request Release Update

   A notification will be sent to THOR, which is an IFS Internal system, when the “Request Release Update” button is clicked and it will generate a sales quotation automatically. Meanwhile, the customer and IFS Customer Success Manager will collaborate and work towards a successful Release Update deployment. - Request Release Update

3. Apply Release Update in Baseline Repo

   Key functionality of the Release Update Studio process. The system will create parallel branches for both customer baseline and customer solution repositories. During the process, it will also update the customer baseline branch to the selected Release Update and fetch & apply the relevant solution set to the baseline repository. The automation for this stage will be completed by running a baseline build. Refer detail documentation - Apply Release Update to Baseline Repository

4. Impact Analysis

   The user actions and automation will be equivalent to the impact assessment except that there is no option to select a Release Update version as the update version is already applied. Refer detail documentation - Impact Analysis

5. Customization Upliftment Preparation

   Automates the creation of topic branch for customization upliftment. During this step a new topic branch will be created and the version will be updated to that of the new Release Update. Once this step is completed, the user can use the created topic branch for customization upliftment. Refer detail documentation - Customization Upliftment Preparation

6. Apply Release Update to Solution Repo and Customization Upliftment

   The user then can fix the conflicts identified during the impact analysis and do the customization upliftment. Refer detail documentation - Apply Release Update to Solution Repo & Customization Upliftment

7. Order Environments

   Refer detail documentation - Order Baseline Environments and Order Topic Environments

8. Order Sanity Build

   The Release Studio sanity build process is similar to the Build Place sanity build process except few differences. Refer detail documentation - Sanity Builds

9. Order Delivery

   Release Studio delivery process is similar to the Build Place delivery process except few differences. Refer detail documentation - Release Update Deliveries

10. Approve Delivery and Deploy in Use Place

    Please note below when approving and deploying Release Update deliveries in Use Place.

    • It is possible to create deliveries in both Build Place and Release Update Studio simultaneously. However, users are recommended to use Build Place only for deliveries containing critical fixes (eg: service updates, other critical fixes, etc) for the customer’s production environment during the period of the release update process. In the meantime, release update work can be done using a different code branch.
    • However, any changes included in deliveries approved & deployed in Use Place via the Build Place after the Release Update process started, should be reapplied in the release update code branch in Release Update studio.
    • Similarly, if any service updates are applied in the Build Place after the Release Update process is started, then the corresponding service update for the intended release also needs to apply in the release update studio.
    • The customer product implementation team is responsible for maintaining the correct delivery sequence by choosing the correct delivery baseline when ordering delivery from Build Place / Release Studio.

11. Test Data Update - Refer detail documentation - Test Data Update

12. Conduct Configuration Analysis & Lobby Analysis

    It is highly recommended to conduct configuration analysis and Lobby analysis, when the Release Update delivery is deployed in non-production environments of use Place. Refer detail documentation in the "Configuration Analyzer" section of the Development Guide in the Technical Documentation.

13. Use Place Setup, Testing and Live Deployment

    Following are the steps should be followed to deploy the Release Update in Use Place.

    • It is recommended, all three Use Place environments (CFG, UAT, Prod) are in same delivery prior to start the Release Update deployment in Use Place. This would simplify the Use Place deployments process.
    • When creating the delivery, customer should select the latest approved delivery tag in Build Place.
    • Implementation team should decide the environment which the Release Update to be deployed for testing purpose. Customer has the option of ordering a new Use Place environment or alternatively, current CFG / UAT environment can be used for this purpose.
    • The selected test environment should be cloned from the Production environment. Please contact IFS support team for assistance related to cloning process for Cloud deployed customers.
    • Test and plan the Release Update deployment in production environment.
    • On successful deployment in production environment, it is recommended to clone the rest of the environments (eg: UAT or CFG) also from the production environment, thus, all three Use Place environments would be in latest release update state.
    • IFS Smart Data Manager tool should be used to migrate Data, if needed, during this process.
    • Customer can decide to complete the Release Update process as specified in section below, soon after deploying the new release in to production.

14. Complete the Release Update Process

    The last step of the Release Update Process is to cutover the Build Place the Release Update which was deployed in Use Place. This should be done once the Release Update deployment is completed in use place environment(s). Until then, any urgent fixes can still be delivered via Build Place. Refer detail documentation - Complete Release Update

    Customers can deploy the delivery to use place/production and continue to do development on RU studio and do the Build Place cutover only when they are ready to do so.

    Once the cutover is done, users will have only the Build Place retained with the new release. Therefore, all Builds and deliveries can be created on the new release track. Parallel track development will no longer be available from the point of cutover.