Taking a Release Update to a Build Place Without Customizations 🆕

Introduction

Below Infographic depicts the business process of taking a Release Update to a Build Place which do not have customizations in the repository.

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

This flow is only applicable for core-cust separated Build Places (i.e. Release Update version you are planning to take is 22R2 or higher). The customers who use the previous versions should refer Taking a Release Update to a Build Place With Customizations.

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

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 "Release Available" button on My Build Places page, as shown 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.

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 Release Studio is able to grasp the current status of the ongoing Release Update.

The following is the summary table for a customer who has their product in 22R2 or beyond.

Once the customer completed the 'Apply Release Update in Baseline Repo' step, if the customer has a "Build Place Without Customizations", the summary table will be displayed as below:

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 are labeled 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 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 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. Apply to Solution and Sanity Build

   Once the Release Update is applied to the baseline repository, the next step is to apply the Release Update to the Customer Solution repository and run a sanity build. When the operation is triggered, the Release Update available in the customer baseline repository will be fetched and applied to the Customer Solution repository. A sanity build will also be run to check for build errors. Refer detail documentation - Apply Release Update to Solution and Sanity Build

5. Apply Service Update and Sanity

   *Note:* This step is applicable only when user is intended to apply a service update to the release-update branch.

   Once the Release Update is applied to the customer baseline and solution repositories, users will have the option to apply service update to their release studio. The next step is to apply the Release Update to the Customer Solution repository and run a sanity build. When the operation is triggered, the selected Service Update will consecutively applied to customer baseline and solution repository. A sanity build will also be run to check for build errors. Refer detail documentation - Applying Service Updates

6. Order Delivery

   Only one delivery can be created from the Release Update flow where customizations do not exist in the repository. Refer detail documentation - Release Update Deliveries

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

8. Conduct Configuration Analysis & Lobby Analysis (If Applicable)

   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.

9. 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 the 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.
   • The customer can decide to complete the Release Update process as specified in section below, soon after deploying the new release in to production.

10. Test Data Update (If Applicable)

11. Complete the Release Update Process

    The last step of the Release Update Process is to cutover the Build Place Release Update which was deployed in Use Place. This should be done once the Release Update deployment is completed in the 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 to detailed documentation - Complete the Release Update Process