Skip to content

Applying Service Updates

Service Update Apply Process

Prerequisites

IFS Update Analyzer downloaded and installed on the users' workstation. The tool can be downloaded from the IFS Developer Portal

Apply a Service Update to the build place

There are three main steps when taking a service update to a Buildplace.

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 select the Buildplace to apply the service update.

    • Click on button "Service Update" in the Buildplace 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 and the availability of service updates. There can have four different scenarios when applying a service update to a Buildplace according to the two factors mentioned above. They are,

    Scenario 1: When the versions of customer baseline and customer solution repositories 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).

    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 Buildplace 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 before applying a service update
    • In this scenario, the below dialog-box appears when clicked on the "Service Update" button in the Buildplace view(Figure 1.4).

    • It contains a warning message recommending to finalize and commit existing customizations prior to applying the service update to avoid merge conflicts.

    • Click the check-box[1] and click on the "Proceed" button[2] to proceed with the service update.

    apply-to-baseline-confirmation
    Figure 1.4 - Scenario 1 - Confirmation dialog-box before applying service update to customer-baseline repository
    • Upon clicking on the "Proceed" button the below dialog-box will appear(Figure 1.5).
    apply-su-to-baseline
    Figure 1.5 - 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 Buildplace'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(Figure 1.6). During this process pipeline will start fetching the selected service update to customer-baseline repository.

    • Clicking on the "Close " button [4], will close the dialog-box and process will be terminated.

    baseline-pending-tag
    Figure 1.6 - Scenario 1 - Baseline repository pending tag
    • Job table record can be viewed by clicking on the "Jobs" button in the top button list in the Buildplace view(Figure 1.7).
    job-button
    Figure 1.7 - 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.8).
    scenario1-baseline-after
    Figure 1.8 - Scenario 1 - Baseline repository version after applying a service update

    Scenario 2: When the versions of customer baseline and customer solution repositories 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.9).

    SU-user-flow-scenario2
    Figure 1.9 - Scenario 2 - User flow of applying a service update to Customer-Baseline repository

    A sample scenario with the versions of Buildplace repositories that matches to this scenario is shown in the below image(Figure 1.10).

    scneario2-baseline-before
    Figure 1.10 - Scenario 2 - Baseline repository version before applying a service update
    • In this scenario, the below dialogbox appears when clicked on the "Service Update" button in the Buildplace view(Figure 1.11).
    service-update-popup-box
    Figure 1.11 - 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.12).

    scenario2-su-option-1
    Figure 1.12 - Apply service update in the baseline repository
    • Once the "Next" button is clicked, confirmation dialog-box will be appeared (Figure 1.4).

    • "Apply Service Update in the Baseline Repository" dialog box (Figure 1.5) will popup when clicked on "Proceed" .

    • Upon clicking on the "Apply" button (Figure 1.6), pipeline will trigger and a 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 customer-baseline repository.

    • Job table record can be viewed by clicking on the "Jobs" button in the top button list in the Buildplace view (Figure 1.7).

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

    SU-user-flow-scenario3
    Figure 1.13 - Scenario 3 - User flow of applying a service update

    A sample scenario with the versions of Buildplace 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 buildplace 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).

    • In this scenario, any of the enabled options can be selected. Choose "Impact Analysis for current Baseline Repository Version" option, if you want to analyze the impact for the customizations from the version of the current baseline repository(Figure 1.16). Then click on the "Download" button. For more info: Impact Analysis for new customer-baseline repository version.

    scenario3-su-option2
    Figure 1.16 - Scenario 3 - Impact analysis for current baseline repository version
    • Choose "Create Topic Branch to Apply the Service Update" option, if you want to apply the version in current baseline repository to current version of the customer solution repository (Figure 1.17). For more info: Apply service update to customer-solution repository
    scenario3-su-option3
    Figure 1.17 - Scenario 3 - Create topic branch to apply the service update

    Scenario 4: When the versions of customer baseline and customer solution repositories 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.18).

    SU-user-flow-scenario4
    Figure 1.18 - Scenario 4 - User flow when buildplace is already up to date

    A sample scenario with the versions of Buildplace repositories that matches to this scenario is shown in the below image(Figure 1.19).

    scenario4-baseline-before
    Figure 1.19 - 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 Buildplace view(Figure 1.20).

    scenario4-already-updated-popup-box
    Figure 1.20 - 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 a Buildplace. 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 "Service Update" button in the Buidlplace view (Figure 1.1).
    • Select the second option[1] in the dialog-box as in the below image(Figure 2.1).
    • Click on the "Download" button[2].
    impact-analysis-option
    Figure 2.1 - Impact analysis option in Service Update popup-dialogbox
    • Once clicked on the "Download" 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 users'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

    Note: Throughout the Apply service update process you can follow these steps whenever you need to run “impact analysis”

  3. Apply Service Update to Customer Solution Repository

    This is the third main step in the process of applying a service update to a Buildplace. 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 "master" branch. To do this, follow the below steps;

    • Click on the "Service Update" button in the Buidlplace view(Figure 1.1).

    • Then the select the third option[1] 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[2] 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 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]
    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/automation/SU-service-update,22.2.1,0001

    git checkout <branch-name>

    Note: If there are no conflicts in your customizations, no need to proceed next step which is to 'Git add, commit and push local changes'. You can directly proceed to ordering a topic environment and then creating the pull request if the topic environment is created successfully.

    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)[1].
    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 Buildplace 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

Delivering a Service Update in a Corrective Delivery

There could be instances where user wants to include a service update in already created delivery. One use case of this would be to fix a bug that was found in the earlier delivery after it was deployed in use place. The bug had been fixed in the most recent service update, but in some scenarios, cannot deliver the service update in a normal delivery as there can be some untested changes existing in customer solution, master branch. In such scenarios it is recommended to use the option of corrective delivery for the chosen service update. The underline affect of this would be already deployed delivery will take as the baseline and will create a new delivery including the selected service update. The workflow needed to deliver a service update in a corrective delivery is described below.

  • First, follow the previous steps mentioned in this document

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

The following additional steps must be performed if the service update is required to solve a critical issue occurring in the customers' use place.

  • Checkout the master branch of the customer solution repository

git clone <customer-solution-repo-url>

cd customer-solution

  • Create a branch from the delivery tag which corresponds to the delivery that is applied in the customers' use place environment, and checkout the branch. The branch name should be similar to the tag name.

git checkout <tag-name> -b <delivery-tag-branch-name>

  • Then push the created branch from the tag to remote repository.

git push origin refs/heads/<delivery-tag-branch-name>:refs/heads/<delivery-tag-branch-name>

  • Open the customer solution azure repository (Figure 3.7)

  • Download the version.txt file from master branch. (Figure 4.1),

  • go to "Files" in customer solution azure repository [1]

  • select the master branch from the top top down list [2]

  • navigate to the folder in "fndbas" => "source" [3]

  • click on "More options" icon of version.txt file [4]

  • select "Download" from available option list [5]

    download-version-txt-file
    Figure 4.1 - Download version-txt file from master branch
  • Copy the downloaded version.txt file from your local download folder and replace it with the version.txt available in created delivery branch, "fndbas" => "source" folder.

Next step of Delivering a Service Update in a Corrective Delivery is analyze the impact of the service update on the customer's use place.

Steps to Analyze the impact of the service update on the customer's use place are described below.

  • Click on the "Corrective Delivery" button in the buidlplace view (Figure 4.2).
corrective-delivery-button
Figure 4.2 - Corrective Delivery button
  • Then the select the "Impact Analysis" option from available list as in the below image (Figure 4.3).
impact-analysis-option
Figure 4.3 - Corrective Delivery - Impact Analysis option
  • Upon clicking the "Impact Analysis" option a " following dialogbox will be poped-up (Figure 4.4).
impact_analysis_dialog
Figure 4.4 - Impact Analysis for Corrective Delivery Dialog

The purpose of this popup-dialogbox is to get the required inputs including "Delivery Baseline tag","Target Service Update tag" that requires for generate upda file generation to perform Impact Analysis.

impact-analysis-for-corrective-del-after
Figure 4.5 - Impact Analysis for Corrective Delivery Dialog when no branch availble for selected Delivery Baseline 
  • There is a text to educate user that this will download the .upda file and the requirement of this step(Figure 4.5).

  • Select the particular Delivery baseline tag from the dropdown[1].

  • Target Branch section will filled automatically with name of the branch which is created from particular delivery tag.[2]

Note: Target Branch section will filled automatically only if a branch existing in azure customer solution repository with the branch name similar to the selected tag. If there is no such branch existing Target Branch section will populate with "No matching branch found for the selected delivery baseline tag." error message. (Figure 4.5)

impact_analysis_dialog_when_no_branch_exist
Figure 4.4 - Impact Analysis for Corrective Delivery Dialog when no branch availble for selected Delivery Baseline 
  • Select the Target Service update from available list which is expecting to apply to the customer's use place.[3]

After Selecting the Target Service Update tag "Download" button will get enabled. [4]

  • Click on the "Download" button. [4]

  • Once clicked on the "Download" button a file with ".upda" extension will be downloaded within two-three seconds to user's download folder.

  • Analyze the impact of the service update on the customer's use place using pre-installed Update Analyzer tool.

Follow the steps similar to Impact Analysis for new customer-baseline repository version section in this document to perform impact analysis using downloaded file.

Note: Even there is no any customization related local changes, it's mandatory to add, commit and push as the version.txt file change is available in local branch.

git add .

git commit -m "meaningful commit message"

git push origin refs/heads/<delivery-tag-branch-name>:refs/heads/<delivery-tag-branch-name>

Final step of Delivering a Service Update in a Corrective Delivery to customer's use place is order a delivery from the portal.

  • Order a delivery from the IFS Lifecycle Experience Portal to creating delivery for the service update.