Skip to content

Applying Service Updates

Overview

This section describes the apply service update process in Release Update Studio. The applying service updates to release update studio process is almost similar to the Apply service update to build place process. There are minor differences specifically on the Impact Analysis process and working branch which are clearly described in this documentation.

Prerequisites

  1. Release update is applied to customer-solution repository
  2. A successful sanity build has been run after applying the release update to customer-solution repository and at least one successful sanity tag exists for the new release update
  3. IFS Update Analyzer downloaded and installed on the users' workstation. The tool can be downloaded from the IFS Developer Portal.

Fetching a Service Update to the Release Update Studio

There are three main steps when taking a service update to a Release Update Studio.

step 1: Apply service update to customer-baseline repository

step 2: Impact Analysis for new customer-baseline repository version

step 3: Apply service update to customer-solution repository

  1. Apply Service Update to Customer Baseline Repository

    Follow the below steps to fetch a service update to Customer Baseline repository.

    • Go to IFS Lifecycle Experience portal and navigate to Release Update Studio view.
    • Click on button "Service Update" in the Release Update Studio view. (Figure 1.1).
    service-update-btn
    Figure 1.1 - Service Update button

    The popup dialog box appears when clicked on the service update button may vary, according to the versions of customer-baseline and customer-solution repositories in release update studio and the availability of service updates. There can have four different scenarios when applying a service update to a release update studio according to the two factors mentioned above. They are,

    Scenario 1: When the versions of customer baseline and customer solution repositories in release update studio are same and IFS has released a new service update

    The highlighted path of the following diagram shows the user flow of applying a service update to Customer Baseline repository (Figure 1.2).

    ru-su-user-flow-scenario1
    Figure 1.2 - Scenario 1 - User flow of applying a service update to Customer-Baseline repository

    A sample scenario with the versions of release update studio repositories that matches to this scenario is shown in the below image(Figure 1.3).

    scenario1-baseline-before
    Figure 1.3 - Scenario 1 - Baseline repository version in release update studio before applying a service update
    • In this scenario, the below dialog-box appears when clicked on the "Service Update" button in the release update studio view (Figure 1.4).
    apply-su-to-baseline
    Figure 1.4 - Scenario 1 - Apply service update in the baseline repository popup-box
    • Select a later service update version from "IFS Cloud Service Update Version" drop-down list[1].
    • Information text educates the user about the outcome of clicking the "Apply" button and the text contains the current version of the release update studio's customer-baseline repository as well[2].
    • Upon clicking the "Apply" button [3], pipeline will trigger and job table record with the status "Pending" will be added by the pipeline itself. During this process pipeline will start fetching the selected service update to release update studio, customer-baseline repository and a text "Pending" will appear at the text-box allocated for the version(Figure 1.5).
    baseline-pending-tag
    Figure 1.5 - Scenario 1 - Baseline repository in release update studio pending tag
      • Job table record can be viewed by clicking on the "Jobs" button in the top button list in the release update studio view (Figure 1.6).
    job-button
    Figure 1.6 - Jobs button
    • Once the pipeline run is successful, the customer-baseline repository version displayed in the repository information card will be updated with the new version as below (Figure 1.7).
    scenario1-baseline-after
    Figure 1.7 - Scenario 1 - Baseline repository version in release update studio after applying a service update

    Scenario 2: When the versions of customer baseline and customer solution repositories in release update studio are different and IFS has released a new service update

    The highlighted path of the following diagram shows the user flow of applying a service update to Customer Baseline repository(Figure 1.8).

    ru-su-user-flow-scenario2
    Figure 1.8 - Scenario 2 - User flow of applying a service update to Customer-Baseline repository

    A sample scenario with the versions of release update studio repositories that matches to this scenario is shown in the below image (Figure 1.9).

    scenario2-baseline-after
    Figure 1.9 - Scenario 2 - Baseline repository version in release update studio after applying a service update
    • In this scenario, the below dialog-box appears when clicked on the "Service Update" button in the release update studio view (Figure 1.10).
    service-update-popup-box
    Figure 1.10 - Scenario 2 - Service Update popup-dialog box

    Initially the "Next" button will be disabled. Upon selecting an option it will be enabled.

    • Choose the first option in the popup-dialogbox to apply a later service update to the baseline repository.

    • Click on the "Next" button to proceed (Figure 1.11).

    scenario2-su-option-1
    Figure 1.11 - Apply service update in the baseline repository in release update studio
    • Once the "Next" button is clicked(Figure 1.11), "Service Update Apply to baseline" dialog box will popup (Figure 1.4).

    • Upon clicking the "Apply"[3] button (Figure 1.4), pipeline will trigger and job table record with the status "Pending" will be added by the pipeline itself. During this process pipeline will start fetching the selected service update to release update studio, customer-baseline repository.

    • Job table record can be viewed by clicking on the "Jobs" button in the top button list in the release update studio view (Figure 1.6).

    • Once the pipeline run is successful, the customer-baseline repository version displays in the repository information card will be updated with the new version as below (Figure 1.12).

    scenario2-baseline-after
    Figure 1.12 - Scenario 2 - Baseline repository version after applying a service update

    Scenario 3: When the versions of customer baseline and customer solution repositories in release update studio are different and there are no new service updates released by IFS

    The highlighted path of the following diagram shows the user flow for this scenario (Figure 1.13).

    ru-su-user-flow-scenario3
    Figure 1.13 - Scenario 3 - User flow of applying a service update to Customer-Solution repository

    A sample scenario with the versions of release update studio repositories that matches to this scenario is shown in the below image(Figure 1.14).

    scenario3-baseline-before
    Figure 1.14 - Scenario 3 - Baseline repository version before applying a service update
    • In this scenario, the below dialogbox appears when clicked on the "Service Update" button in the release update studio view (Figure 1.15).
    scenario3-su-popup-box
    Figure 1.15 - Scenario 3 - Service Update popup-dialog box
    • The 1st option ("Apply Service Update in the Baseline Repository") of this dialog-box will be disabled as there are no any later service update version to apply to the baseline repository.

    • Initially "Next" button also will be disabled and it will be enabled upon clicking on a radio button(Figure 1.15).

    • Choose "Create Topic Branch to Apply the Service Update" option, if you want to apply the version in baseline repository of release update studio to current version of the customer solution repository of release update studio(Figure 1.16). For more info: Apply service update to customer-solution repository

    Note: Before choosing "Create Topic Branch to Apply the Service Update" option, Impact Analysis should be done. For more info: Impact Analysis for new customer-baseline repository version.

    scenario3-su-option2
    Figure 1.16 - Scenario 3 - Create topic branch to apply the service update

    Scenario 4: When the versions of customer baseline and customer solution repositories release update studio are same and there are no new service updates released by IFS

    The highlighted path of the following diagram shows the user flow for this scenario (Figure 1.17).

    ru-su-user-flow-scenario4
    Figure 1.17 - Scenario 4 - User flow for already up-to-date user

    A sample scenario with the versions of release update studio repositories that matches to this scenario is shown in the below image(Figure 1.18).

    scenario4-baseline-before
    Figure 1.18 - Scenario 4 - Create topic branch to apply the service update

    In this scenario, the below dialog-box appears when clicked on the "Service Update" button in the release update studio view (Figure 1.19).

    scenario4-already-updated-popup-box
    Figure 1.19 - Scenario 4 - Already up-to-date popup-dialogbox
  2. Impact Analysis for New Customer Baseline Repository Version

    This is the second main step in the process of applying a service update to the release update studio. After the Customer Baseline repository has been updated with the service update, the Update Analyzer tool can be used to analyze the impacts of fetching this update to the Customer Solution which contain the customizations. To do this, follow the below steps;

    • Click on the "Impact Analysis" button in the release update studio view (Figure 2.1).
    impact-analysis-option
    Figure 2.1 - Impact analysis option in Service Update popup-dialogbox
    • Once clicked on the "Impact Analysis" button a file with ".upda" extension will be downloaded within two-three seconds to user's download folder.

    Note: To do the impact analysis, Update Analyzer tool needs to be installed in the user's machine. Please refer Update Analyzer Installation Steps to find the step-by-step guide on how to install the Update Analyzer tool.

    • On a machine which has pre-installed Update Analyzer, the file can be opened by double-clicking or by selecting the option “Open with Update Analyzer”.

    • The file will then open in Update Analyzer and will start cloning the repositories and will then run the impact analysis(Figure 2.2). The process will continue for approximately 5-15 minutes and complete.

    upda-cloning
    Figure 2.2 - Already up-to-date popup-dialogbox
    • At the completion of the analysis, a report will be generated with an overview of layer and interface impacts, categorized by the severity of the impacted files as high, low, no, and unknown files (Figure 2.3).
    upda-analyzer-impacts-overview
    Figure 2.3 - Overview of the impacts shown in Update Analyzer

    Further, by clicking on one of the rows, a detailed diff analysis of those files can be viewed. For further details: For more info: Update Analyzer Analyzing Impacts

  3. Apply Service Update to Customer Solution Repository

    This is the third main step in the process of applying a service update to the release update studio. After the impact of the service update to the customizations has been identified by the impact analysis step, it is possible to apply the service update to customer solution repository "relese-update" branch. To do this, follow the below steps;

    • Click on the "Service Update" button in the release update studio view(Figure 1.1).

    • Then the select the second option in the popup-dialogbox as in the below image(Figure 3.1).

    create-topic-branch-option
    Figure 3.1 - Create topic branch to apply the service update option
    • Upon clicking the "Next" button a dialogbox will be poped-up (Figure 3.2).

    The purpose of having this popup-dialogbox is to get the topic branch name for the automation pipeline as an input, to commit the new version.txt file as the automation pipeline has partially automated the merging of version.txt file to the customer-solution repository,"relese-update" branch during a service update. Thereafter, the above created topic branch should use for the customization upliftment process.

    • There is a text to educate user that the topic branch will be created with the name shown in the popup-dialogbox(Figure 3.2).

    • As in the above image, the topic branch name will be "topic/automation/SU-service-update.22.2.1,0001" [1,2].

    • "Edit Name" button can be used to edit the placeholder[2] of the generated topic branch name which is a unique, generated number.

    • Topic branch name placeholder field[2] keeps disabled until the "Edit Name" button is clicked[3].

    • By clicking on the "Edit Name" button, it is possible to edit the generated number if it is required[3].

    Note: However, editing the autogenerated branch name is optional. If the user want to create the branch name in a user specific way, then the "Edit Name" option can be used. However, autogenerated branch name is unique for each user.

    create-topic-branch-popup-dialogbox
    Figure 3.2 - Create topic branch to apply the service update option
    • When the suffix of the topic branch name is changed[1],
      • the "Edit Name" button text turns to "Check"[2].
      • the "Create" button gets disabled.
    topic-branch-name-change
    Figure 3.3 - Create topic branch to apply the service update option

    By clicking on the "Check" button, it is possible to check if the auto-generated branch name already exists in the customer solution azure project repository. If the branch is already exists in the user's customer solution azure repository it is not possible for the automation pipeline to create the topic branch. - Click the "Check" button. During the time of checking the existence of the edited topic branch name, - An information text highlighted in yellow colour will be visible above the buttons as in the below image (Figure 3.4) - The "Check" button turns to a spinner (Figure 3.4)

    checking-topic-branch-name
    Figure 3.4 - Checking updated topic branch name
    • Upon the completion of checking the existence of the updated branch name, if the updated branch name not exists in the customer solution azure repository(Figure 3.5),
    • a text highlighted in green colour[2] will be appeared
    • "Check" button also gets disables unless branch name is not changed[1]
    • The "Create" button gets enabled[3]
    valid-topic-branch
    Figure 3.5 - Valid topic branch name
    • Upon the completion of checking the existence of the updated branch name, if the updated branch name already exists in the customer solution azure repository(Figure 3.6),

    • A text highlighted in red colour[2] will be appeared

    • "Check" button also gets disables unless branch name is not changed[1]
    • The "Create" button keeps disabled[3].
    invalid-topic-branch
    Figure 3.6 - Already existing topic branch name
    • If the user gets the above output, try using a different branch name by changing the suffix of the branch name(Figure 3.6).
    • If the user gets the output shown in the figure 3.5, click on the "Create" button to proceed.

    • At this point a job table record will be created for the topic branch creation by the automation pipeline. Job records can be viewed by navigating to the jobs view by clicking on the "Jobs" button(Figure 1.5).

    • Once the topic branch creation pipeline is success, a success toast message will appear otherwise it will show a failure toast.

    • At this point the automation pipeline has created a topic branch in the customer solution repository with the name specified and has been pushed the new version.txt file to the branch.

    • Branch details can be seen by going to the customer solution azure repository by clicking on the link icon(Figure 3.7).

    navigate-to-cs-repo
    Figure 3.7 - Valid topic branch name
    • To check if the topic branch specified in the previous steps, has been committed (Figure 3.8),
    • go to the "Branches" [1]
    • select "All" tab[2]
    • Click on the branch name which has been created by the automation pipeline[3,4]
    azure-topic-branch
    Figure 3.8 - Valid topic branch name
    • To check if the new version.txt file has been committed to the topic branch(Figure 3.9)
    • go to "Files" in customer solution azure repository [1]
    • select the topic branch name from the top top down list[2]
    • navigate to the folder in "fndbas" => "source" [3]
    • open the version.txt file and check the correct service update version contains there[4].
    version-txt
    Figure 3.9 - Updated version.txt file
    • After verifying that the version.txt has been correctly committed to the topic branch, follow the below steps to manually uplift the customizations.
    If there are customizations in the customer solution repository
    • Clone Customer Solution repository. Customer solution repository url can be taken by clicking on the copy icon which is located next to the link icon as in Figure 3.7.

    git clone <customer-solution-repo-url>

    • Change directory to the cloned folder.

    cd customer-solution

    • To fetch the branch name created by automation, use following instructions.
    • List all branches in remote repository

      git branch -r

    • Copy and and keep branch name created by automation for later steps.

    topic-branch-name-fetch
    Figure 3.10 - Fetch topic branch name
    • Checkout the topic branch which was created by the automation pipeline.

    eg: git checkout topic-ru/automation/SU-service-update,22.2.1,0001

    git checkout <branch-name>

    git add .

    git commit -m "meaningful commit message"

    git push origin <branch-name>

    git branch -d <branch-name>

    • Delete remote topic branch(Figure 3.11).
    delete-remote-topic-branch
    Figure 3.11 - Delete remote topic branch
    • Check if the customer solution repository version has been correctly updated in "Repository Information " card in the release update studio view.
    cs-repo-version
    Figure 3.12 - Customer solution repository version after merging the topic branch
    If there are no customizations in the customer solution repository