Applying Service Updates

Related Pages

• IFS Update Analyzer
• Working with pull requests
• Ordering  Deliveries
• Segregate Core and Customization code base
• Developing with Dev-Studio

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

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

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

   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.

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

   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.

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

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

   Figure 1.8 - Scenario 1 - Baseline repository version after applying a service update

   • Continue from Impact Analysis for new customer-baseline repository version

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

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

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

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

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

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

   • Continue from Impact Analysis for new customer-baseline repository version

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

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

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

   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.

   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

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

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

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

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

   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.

   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 impacts, categorized by the severity of the impacted files as high, low, no, and unknown files (Figure 2.3).

   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

   • Continue from Apply service update to customer-solution repository

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

   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.

   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.

   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)

     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]

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

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

   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]

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

   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

   • Create and checkout the topic branch

     If you already have the cloned customer-solution repository in your machine, it is recommended to use the existing clone for a better experience, instead of cloning the repository anew for each Buildplace activity.

     If the cloned customer-solution repository exists locally on the machine run the following git commands

     • Checkout the master branch.

     git checkout master
     

     • Update the locally existing customer-solution repository with the latest changes in the master branch of the remote repository .

     git pull origin  master
     

     • Checkout topic branch. Topic branch name can be copied by using the copy icon appear when hover the topic branch in the azure repository as in Figure 3.8 [4]. Eg: git checkout topic/automation/SU-serviceUpdate,23.2.1,0001

     git checkout <topic-branch-name>
     

     git pull origin <topic-branch-name>
     

     If the cloned customer-solution repository does not exist locally on the machine proceed with the following guidelines

     Note: If you do not have the cloned customer-solution repository of the particular Buildplace in your machine, make sure to clone only the specific branch of the customer-solution repository.

     • To clone the topic branch created by the automation, follow the below commands.

     • The URL can be obtained by clicking on the copy icon as in Figure 3.7 [2].

     • By hovering over the topic branch in the azure repository as in Figure 3.8 [4] , you can copy the name of the topic branch using the copy icon.

     eg: git clone --branch topic/automation/SU-serviceUpdate,23.2.1,0001 --depth 1 https://org-name@dev.azure.com/org-name/bpname/_git/customer-solution

     git clone --branch <topic-branch-name> --depth 1 <customer-solution-repo-url>
     

     • Change directory to the cloned folder.

     cd customer-solution
     

4. Carry out required changes identified by impact analysis. If needed it is possible to rerun the downloaded .upda file in the Impact Analysis for new customer-baseline repository version step.

5. There are some existing features in the Update Analyzer tool that can be used to make the process of handling the impacts of non-layered easily. Handling impacts of non-layered files

   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, commit and push local changes (Refer Naming Standards to use when working with GIT for the commit message naming standard)

   git add .
   

   git commit -m "meaningful commit message" 
   

   git push origin <branch-name>
   

   • If there are corrections done in core files as a temporary fix for a bug in a core file(s) and the actual fix has been released in the applying service update, refer this documentation to remove the core files from customer-solution repository. When there are fixes done in core files as a temporary fix for a bug in a core file(s)

   • Test the changes using a topic environment. Refer Environments created from a topic branch for more details.

   • Create pull request to merge the topic branch to Customer Solution repository master branch. Refer Working With Pull Requests for more details.

   Note: Make sure to add a meaningful Pull Request description that is relevant to the commits contained in the PR. This will be included in reports generated by the portal.

   • Merge the Pull Request to Customer Solution repository master branch. Refer Working With Pull Requests for more details.

   • Delete local topic branch.

   git branch -d <branch-name>
   

   • Delete remote topic branch(Figure 3.11)[1].

   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.

   Figure 3.12 - Customer solution repository version after merging the topic branch

   • Run a sanity build and proceed with creating delivery

   If there are no customizations in the customer solution repository

   • Create pull request to merge the topic branch to Customer Solution repository master branch. Refer Working With Pull Requests for more details.
   • Merge the Pull Request to Customer Solution repository master branch. Refer Working With Pull Requests for more details.
   • Delete remote topic branch(Figure 3.11)[1].
   • Run a sanity build and proceed with creating delivery

   Note:

   In case, if the delivery fails and it was identified as a defect in the core files, then the recommended process is to apply the next service update which includes the fix as well. However, there can be a scenario where the customer needs to apply the fix urgently due to the business urgency. In such scenarios refer "Taking temporary fix for a defect in core file" for the process.

   Reverting a Service Update

   There are more unlike scenarios where customers need to revert the service update during the service update applying process. However, this method is recommended only if the service update process cannot be continued.

   Reverting service update from customer-solution repository

   If the Service Update applied to the Solution Repository is to be reverted, follow the below steps:

   • Go to the azure customer solution repository
   • Switch to the correct branch (master)
   • Go to the commit you want to reset from your repository (the commit of applying new service update)
   • Click on the icon in left top corner and select the revert option from the list (Figure 4.1) and confirm.

   Figure 4.1 - Reverting a commit

   • Then a revert PR will be created.
   • Get approval for the PR from the authorized user and merge the revert PR to the master branch.

Note: It is not possible to revert a Service Update once applied to the Baseline 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.

• Create and checkout the Corrective Delivery branch

  If the cloned customer-solution repository exist locally in the machine

  • Checkout the master branch of the customer solution repository and update the master branch with the latest changes in the remote repository.

    git checkout master
    

    git pull origin master
    

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

  If the cloned customer-solution repository does not exist locally in the machine

  • Go to azure customer-solution repository (Figure 3.7)
  • Click on "New branch" button (Figure 5.1) [1] .

  • Fill the "Name" field with the name corresponds to the delivery that is applied in the customer's use place. Eg: del-ifs-cloud-23.2.1-abc001-2.2.0-20230713T175538Z-OK [2]

  • Click on the drop down icon located in the "Based on" field [3]

  Figure 5.1 - Create Corrective Delivery Branch

  • Switch to the "Tags" tab in the drop-down (Figure 5.2) [1]

  • Select the delivery tag which corresponds to the delivery that is applied in the customer's use place, from the tag list.

    Figure 5.2 - Select the base delivery tag for the delivery branch

    Note: The name of the delivery tag selected here and delivery name given in the above step must be equal.

  • Click on "Create" button. (Figure 5.3)

    Figure 5.3 - Create corrective delivery branch

  • Run the below git command to clone the delivery branch to the local machine.

    Eg: git clone --branch del-ifs-cloud-22.2.6-abc001-1.0.0-20230331T022455Z-OK --depth 1 https://azure-org@dev.azure.com/azure-org/abc001/_git/customer-solution

    git clone --branch <delivery-tag-branch-name> --depth 1 <repository-url>
    

    cd customer-solution
    

Follow the below steps to add changes to the corrective delivery branch.

• Open the customer solution azure repository (Figure 3.7)

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

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

• Select the master branch from the top drop 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]

  Figure 5.4 - 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 5.5).

Figure 5.5 - Corrective Delivery button

• Then the select the "Impact Analysis" option from available list as in the below image (Figure 5.6).

Figure 5.6 - Corrective Delivery - Impact Analysis option

• Upon clicking the "Impact Analysis" option a " following dialogbox will be poped-up (Figure 5.7).

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

Figure 5.8 - 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 5.8).

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

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

• If there is any customizations identified in update analysis,

• Uplift those customizations.

  • There are some existing features in the Update Analyzer tool that can be used to make the process of handling the impacts of non-layered easily. Handling impacts of non-layered files

• Git add, commit and push local changes (Refer Naming Standards to use when working with GIT for the commit message naming standard)

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