Skip to content

Apply Release Update to Customer Solution Repository and Customization Uplifting Process

Overview

This section describe the process of migrating release update code from customer baseline repository to the customer solution repository and the process of uplifting customizations

Pre-requisite

Process

During fetching release update to the build place (Fetch the Release Update to Customer Baseline Repository) release-update branch will be created in the customer solution repository from the selected delivery tag. Release update code can be applied to that branch using the following steps.

  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 release-update branch.

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

    e.g.: git checkout -b topic-ru/vinvlk/RU-ALE-01-ReleaseUpdate,22.1 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 1.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.

    VI-editor
    Figure 1.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 2.1).

    git diff

    Figure 2.1 - Git diff output when there are merge conflicts
    • Run Update Analyzer to identify the impacts

    When you pull the upstream to apply the release 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 master 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 2.2). This output log should not contain any '<<<<<<< HEAD' tag.
    conflicts-resolved-with-diff
    Figure 2.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 3.1).

    merge-conflicts-log
    Figure 3.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 3.2)
    merge-conflict-branch
    Figure 3.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 3.3).

    git diff

    Figure 3.3 - Git diff output when there are merge conflicts
    • To accept all the incoming changes run the below command (Figure 3.4)

    git checkout --theirs *

    accept-incoming-changes
    Figure 3.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 3.5) by running git diff command, you are good to go.

    git diff

    conflicts-resolved-no-diff
    Figure 3.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 3.6).
    conflicts-resolved-with-diff
    Figure 3.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 4.1.
    commit-fixed-merge-conflicts
    Figure 4.1 - Branch status when conflicts have been resolved 
  7. Test the changes using a baseline environment or 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 that the buildplace is being updated to. In Azure Devops 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 5.1). switch the master branch into the release-update branch before creating the pull request as shown in Figure 5.2.

    PR-wrong
    Figure 5.1 - Merging the topic branch to the master branch of the Customer Solution Repository
    Figure 5.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 5.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.

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


| pr-merge-option | | :----------------------------------------------------------: | | Figure 6.1 - Pull Request merge options |


#### Check if the versions in the buildplace are correctly updated

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

    versions-berfore-merge
    Figure 7.1 - Buildplace repository versions before merging the release to customer solution repository
    versions-after-merge
    Figure 7.2 - Buildplace repository versions after merging the release to customer solution repository

    Delete remote and local topic branches.

  2. Delete the remote topic branch from the azure repository (Figure 7.3).

    Note: Don't delete the branch if a topic environment has been ordered pointing to the topic branch used to apply the release update and that topic environment creation is in progress.

    delete-topic-branch
    Figure 7.3 - Delete the remote topic branch 

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

When you created the pull request to merge the release 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 8.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 8.1 - Pull Request merge conflict
  • If you are already in the release update topic branch you can skip this step.
git checkout <branch-name>
  • Then pull the changes from the remote customer solution repository release-update branch to the local release-update branch to be up-to-date with the remote release-update (Figure 8.2).
git pull origin release-update
Figure 8.2 - Git pull origin release-update command
  • Resolve merge conflicts if exists.
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 9.1) and head tag as below (Figure 9.2).

sanity-fail-log
Figure 9.1 - Code generation error message
Figure 9.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 9.3).
commit-sha
Figure 9.3 - How to get the commit SHA

When multiple developers working on customization uplifting process

This section describes the process for uplifting customizations by multiple developers.

  1. Follow the step 1 to 6 in above section
  2. Skip the step 7 and 8 and follow step 9 to push the topic branch created in step 4 to the customer solution repository
  3. All developers share the topic branch created in step 4 to uplift customizations
  4. Developers can deploy the code and test the changes either using a baseline environment
  5. Topic environment can also be used to test the changes once all the build errors in the topic branch are fixed
  6. Commit the local changes to the topic branch by following the step 9 in above section
  7. Once all the customizations are uplifted follow step 10 and 11 in above section