Release Update Studio

Introduction

The release update studio allows customers to be truly evergreen, take advantage IFS’s constant innovation and get fast access to new technology. The studio is designed to ensure customers and partners experience a repeatable and predicable process during the release update – from analyzing changes, through to applying the updates.

Prerequisites

• Release Update functionality is applicable for customers who are on IFS Cloud 21R1 and above only.
• Existing customers on IFS Cloud 21R1 should have Service Update 5 or above applied in Use Place prior to commencing the Release Update Process.
• Middle-tier (AKS Cluster) of Build Place should be upgraded to 1.20.7 or above prior to beginning the Release Update Process. Additionally, the middle-tier cluster of Use Place also should be upgraded as above, when the customer has chosen Cloud Deployment Model.

Below Infographic depicts the business process of Release Update Studio.

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

User is expected to check whether adequate Build Place environments and user counts are in place order. It is 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 required. Process of increasing resources in given below.

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

Getting Started

Users are able to login to Release Update Studio by clicking the new button introduced in "My Build Places" page, as referred below.

Upon login to 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 action will be enabled.

The second layer would show the customer and repository information.

Third section would provide a snap shot of the current status of the release update process. This functionality makes the collaboration easy where any user who login to release studio is able to grasp the current status of the ongoing release update.

Forth section of the screen is the information on environments. User has the option of ordering environments similar to the Build Place and environments which are ordered via Release Update studio is labeled for easy reference.

User Journey

1. Conduct Impact Assessment

   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 developr.ifs.com site. Refer detail documentation - Impact Assessment

2. Request Release Update

   A notification will be sent to THOR, which 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

   Key functionality of the Release update studio process. The system will create parallel branches for both customer baseline and customer solution repository. 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 complete by running a baseline build. Refer detail documentation - Apply Release Update

4. Impact Analysis and Customization Upliftment

   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. User then can fix the conflicts and do the customization uplift. Refer detail documentation - Impact Analysis and Customization Upliftment

5. Order Environments

   Refer detail documentation - Order Baseline Environments and Order Topic Environments

6. Order Sanity Build

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

7. Order Delivery

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

8. 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 release update process. In the meantime, release update work can be done using a different code branch.
   • However, any changed 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.

9. 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 section of the Development Guide.

10. 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.

11. 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.

    Customers can deploy the delivery to use place/production and continue to do development on RU studio and do the Build Place cut-over 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 cut-over. Refer detail documentation - Complete the Release Update Process