Applying Service Updates

Overview

This section describes the apply service update process in Release Update Studio.

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

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.
• Select the target service update from the drop down.
• Click on 'Apply' (Figure 1.1).

Figure 1.1 - Service Update Dialogbox

Once the service update has been applied to the customer baseline repository, a "Pending" status will be displayed for the Customer Baseline Repository. Once the service update is successful, the tag will indicate the new update.

Analyzing the impact of the Service Update

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;

• Open the Update Analyzer tool and select the Git integration button (Figure 2.1).

Figure 2.1 - Update Analyzer git intergration dialogbox

• Provide below information to Update Analyzer GIT-Info dialog

  • Customer Baseline repository URL
  • Customer Solution repository URL
  • An empty folder to checkout files
    • Note:  Provide a directory with a short path to avoid errors with cloning files having long directory paths. [This error occurs due to the windows limitation on file path length]
  • Path to git.exe file

• After entering Customer Baseline repository URL, click on button "Get Tags".

• Base and Target UPD drop downs will be populated with tag names in Customer Baseline repository.

• Select appropriate base and target tags from the drop downs. Base UPD refers to current update of the Customer s]Solution and the Target UPD refers to the update to be moved on to.

• After entering Customer Solution repository URL, "master", "delivery branch" and "release-update" radio buttons get enabled.

• Select the "release-update branch" option to analyze the impacts for customizations in Customer Solution repository release-update branch.

• Upon checking the option, tool will run a validation to check if the release-update branch exists in Customer Solution repository.

• If release-update branch does not exist, the selection will be automatically changed to the master branch option.

• Once all input fields are filled in, click on button "Checkout Files".

• Update Analyzer will create three folders inside the location given to checkout files

  • Base folder: Will contain a shallow clone of Base UPD tag
  • Target folder: Will contain a shallow clone of Target UPD tag
  • Cust folder: Will contain a shallow clone of Customer Solution repository release-update branch

• Once all three clones have been completed, click on button "Proceed Analysis".

• Update Analyzer will then extract the customized files from Cust Folder and move them to a new folder called "ExtractedCust".

• A list of file names extracted into this folder could be found in file "Customized Files.txt" inside the checkout location.

• Paths to Base folder, Target folder and ExtractedCust folder will be populated into Update Analyzer main window at the end of extract operation.

• Perform update analysis, a component structure analysis will be performed with the given input fields.

Merge the Service Update to the release-update branch

Service update can be merged to the release update branch in the customer solution repository by following the steps mentioned below.

1. Clone Customer Solution repository.

   git clone <customer-solution-repo-url>

2. Change directory to the cloned folder.

   cd customer-solution

3. Add Customer Baseline repository as an upstream to Customer Solution repository.

   git remote add upstream <customer-baseline-repo-url>

4. Create and checkout a topic branch based on the release-update branch.

   git checkout -b <topic_branch_name> origin/release-update

   e.g.: git checkout -b topic-ru/piselk/RU-ALE-01-ServiceUpdate,21.2 origin/release-update

   Note: Use proper naming standard as mentioned in Naming Standards to use when working with GIT. If not branch may not be listed in environment ordering dialog.

5. Pull from upstream. ( i.e. from Customer Baseline repository release-update branch)

   git pull upstream release-update -X rename-threshold=95

   Sometimes VI editor(Figure 3.1) will be opened up during the auto merge process of the git pull command. In that case press "Esc"(Escape key) then ":q!" to quit the editor without saving.

   Figure 3.1 - Git VI editor

   Follow the below steps if the customer solution repository contains customizations.

   • Run git diff command. If there are merge conflicts, the output will contain '<<<<<<< HEAD' tag as mentioned in the below image (Figure 4.1).

   git diff

   Figure 4.1 - Git diff output when there are merge conflicts

   • Run Update Analyzer to identify the impacts

   When you pull the upstream to apply the service update into topic branch, you may get merge conflicts from modified and unmodified files. In that case resolve only the real conflicts occurred to core files (non-layered) due to the customizations, by looking at the Update Analyzer result. However, Update Analyzer will list both impacted layered and non-layered files. Do not manually resolve the other conflicted files (unmodified files). Then run the below git commands.

   • Stage the manually resolved files individually. eg: git add accrul/source/accrul/TaxBook.plsql

   git add <path_to_conflicted_core_file>

   • Run the following command to accept all incoming changes from upstream release-update branch to resolve the rest of the conflicts on unmodified files.

   git checkout --theirs *

   • Carry out required changes identified by Impact Analysis run to uplift customizations. Refer Developing with IFS Developer Studio for more information on how to use Developer Studio tool for this.

   • After resolving conflicts and carrying out the required changes identified during the customization upliftment, run the git diff command. You will get an output as below, highlighting the removed and added contents (Figure 4.2). This output log should not contain any '<<<<<<< HEAD' tag.

   Figure 4.2 - Output when there are new changes and no merge conflicts

   • Continue from the step 6

   Follow the below steps if the customer solution repository does not contain customizations.

   Even though there are no customizations in the customer solution repository, merge conflicts may contain in the solution-set file. If the local repository contains conflicts after running pull upstream release-update command, git terminal log should contain a warning message as mentioned below (Figure 5.1).

   Figure 5.1 - Git terminal log message for merge conflicts

   Therefore, follow these precautions to avoid merging the topic branch to release-update branch with merge conflicts.

   • Identify if there are merge conflicts (Figure 5.2)

   Figure 5.2 - Branch name when there are merge conflicts

   • Run git diff command. If there are merge conflicts, the output will contain '<<<<<<< HEAD' tag as mentioned in the below image (Figure 5.3).

   git diff

   Figure 5.3 - Git diff output when there are merge conflicts

   • To accept all the incoming changes run the below command (Figure 5.4)

   git checkout --theirs *

   Figure 5.4 - Git accept all incoming changes

   • After accepting all the incoming changes, ensure that there are no merge conflicts. If you get an output as below (i.e with no <<<<<<< HEAD tag, Figure 5.5) by running git diff command, you are good to go.

   git diff

   Figure 5.5 - Output when accept all incomming changes

   • If additional changes have been done during the time of resolving conflicts you will get an output as below, highlighting the removed and added contents (Figure 5.6).

   Figure 5.6 - Output when there are new changes and no merge conflicts

   Move changes to the remote topic branch

6. 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 <topic branch name>

   • Once the merge conflicts have been resolved, the status of the branch will be changed to the normal state as shown in Figure 6.1.

   Figure 6.1 - Branch status when conflicts have been resolved

7. Test the changes using a topic environment.

   Follow the below steps to Create the Pull Request

8. Before creating the pull request, check if the version in the version.txt file has been updated to the version that the buildplace is being updated to. In azure project repository, go to the correct topic branch that you are working on. Then

   • Go to "fndbas" component
   • Go to "source" folder
   • Check if the version of the version.txt has been correctly updated

9. Create a pull request from the Azure DevOps project. When performing this step, you may notice that Master branch of the Customer Solution repository will be automatically selected in the dropdown (Figure 7.1). switch the master branch into the release-update branch before creating the pull request as shown in Figure 7.2.

   Figure 7.1 - Merging the topic branch to the master branch of the Customer Solution Repository

   Figure 7.2 - Selecting the release-update branch to merge from the dropdown

   • Once the branch is switched, the PR should appear as shown in Figure 5.3.

   Figure 7.3 - Merging the topic branch to the release-update branch of the Customer Solution Repository

   Note: Please refer [What to do when there are merge conflicts in the PR?] if you get merge conflicts in your pull request

   Note: Before reviewing the Pull Request reviewer should ensure if the developer has created the PR pointing to the correct branch.

   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.

   Follow the below steps to Merge the Pull Request

10. The next step is merging the topic branch to customer-solution repository release-update branch.

    Note: Once the pull request is approved, before completing the Pull Request, check if the PR merge option chosen is "Merge (no fast forward)" (Figure 8.1) . Do not select other merge types, as the repository will end-up with a lot of merge conflicts when getting future service updates or release updates and repository will end-up in an unmanageable state.

    Figure 8.1 - Pull Request merge options

    Check if the versions in the buildplace are correctly updated

11. Go to the RU studio and check whether the version tags are correctly updated after merging. Sample images are shown below (Figure 9.1, 9.2).

    Figure 9.1 - Buildplace repository versions before merging the release to customer solution repository

    Figure 9.2 - Buildplace repository versions after merging the release to customer solution repository

    Delete remote and local topic branches.

12. Delete the remote topic branch from the azure repository (Figure 9.3).

    Note: Don't delete the branch if a topic environment has been ordered pointing to the topic branch used to apply the service update, is in progress

    Figure 9.3 - Delete the remote topic branch

13. Run a sanity build and proceed with creating delivery

What to do when there are merge conflicts in the pull request?

When you created the pull request to merge the Service Update changes with the customer solution repository release-update branch, there can have situations were merge conflicts occur between the changes of release update topic branch and the new changes in the release-update branch added by parallel branches ( i.e when your topic branch is not up-to-date with remote release-update branch ) (Figure 10.1). In that case before merging the pull request, we advice you to follow the below steps.

Note: Do not rebase the topic branch with release-update branch, as the repository will end-up with a lot of merge conflicts when getting future service updates and repository will end-up in an unmanageable state.

Figure 10.1 - Merge Conflicts in Pull Request

If you're not in the branch checkout to the topic branch else skip this.

git checkout <branch-name>

Then pull the changes from the remote customer solution repository release-update branch for the local release-update branch to be up-to-date with remote release-update (Figure 10.2).

git pull origin release-update

Figure 10.2 - Git pull origin release-update

Resolve merge conflicts if have.

git add .

git commit -m "commit-message"

git push origin <branch-name>

Now the pull request will be updated with the release-update branch changes.

What to do if the code has been merged with conflicts?

Sometimes there can be situations where the code has been merged to release-update or master branch with conflicts during the apply release update to customer solution repository stage or apply service update process. This will cause both the sanity build and topic environment creation fail during code generation. Usually this happens when there are no customizations and user assumes that there will not be any merge conflicts due to not having customizations. But there can be situations where contain merge conflicts in the solution-set file. You can find the log folder of the failed sanity build or topic environment creation by going to the log view. There you can find the log folder and download it.

For an example, if the sanity build has failed due to the merge conflicts, download the log folder named as "sanity-build-error-full-logs.zip" and go to "\ifs\cbs\code_generation" location and open _ifs_ant_generateddb.log file. There you will see error messages (Figure 11.1) and head tag as below (Figure 11.2).

Figure 11.1 - Code generation error message

Figure 11.2 - Conflict with head tag

According to the error message you can find the file you have committed with conflicts. Then raise a support ticket with all the failed log files , information with the screenshots and the commit SHA of the commit point where you want the repository reset back to, immediately.

How to get the commit SHA:

1. Go to the azure customer solution repository
2. Switch to the correct branch (master/release-update)
3. Go to the commit point where you want the repository reset back to (probably the point before the commit with merge conflicts)
4. Copy the value as mentioned below and paste it in the description of the support ticket (Figure 11.3).

Figure 11.3 - How to get the commit SHA