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

Release update should have been fetched to the build place (Refer Fetch the Release Update to Customer Baseline Repository ).

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. As core code has been removed from customer repositories with 22R2 release, release-update branch in customer-solution repository will now contain only the customized files. 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. Checkout the topic branch created in Customization Upliftment Preparation step

    • git checkout -b <topic_branch_name> origin/<topic_branch_name>

      E.g.:

      git checkout -b topic-ru/automation/RU-releaseUpdate,22.2 origin/topic-ru/automation/RU-releaseUpdate,22.2

      Note: It is mandatory that the branch created in the Customization Upliftment Preparation step is used, as it contains the new release version updated in the version.txt file.

  4. Pull changes from remote topic branch

    • git pull origin <topic_branch_name>

      E.g.:

      git pull origin topic-ru/automation/RU-releaseUpdate,22.2

  5. Update solutionset.yaml file, translation.usage.json file and uplift customizations (if exist)

    • If there are no customizations in the Build Place:

      Download solutionset.yaml file and translation.usage.json file from customer-baseline repository release-update branch and copy to the relevant folder path in local topic branch.

    • If there are customizations in the Build Place:

      Carry out required changes identified by Impact Analysis run to update solutionset.yaml file and translation.usage.json file and to uplift customizations. Refer Developing with IFS Developer Studio for more information on how to use Developer Studio tool for this. Refer Handling impacts of non-layered files for more information on using Update Analyzer tool to handle impacts of non-layered files.

  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>

  7. Test the changes using a topic environment.

  8. Create a pull request from the Azure DevOps project. When performing this step, you may notice that the topic branch will automatically be merged into the Master branch of the Customer Solution repository (Figure 1.1), if you proceed.

    Instead, switch the master branch in to the release-update branch before creating the pull request as shown in Figure 1.2.

    Figure 1.1 - Merging the topic branch to the master branch of the Customer Solution Repository
    Figure 1.2 - Selecting the release-update branch to merge from the dropdown

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

    Figure 1.3 - Merging the topic branch of the Customer Solution Repository 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

  9. Merge 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 2.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 2.1 - Pull Request merge options
  10. Delete remote and local topic branches.

What to do when there are merge conflicts when do pull upstream?

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 *
  • Git add, commit and push local changes to the remote repository
git add . 
git commit -m "meaningful commit message"
git push origin <branch-name>

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 master 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 3.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 3.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 master branch for the local master branch to be up-to-date with remote master (Figure 4.1).

git pull origin release-update
Figure 4.1 - 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.

Multiple developers working on customization uplifting process

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

  1. Follow the step 1 to 7 in the above section.

    Note: All developers must share the topic branch created in the Customization Upliftment Preparation step.

  2. Once all the customizations are uplifted, follow steps 8, 9 and 10 mentioned above to create a Pull Request and Merge the topic branch to Customer Solution repository's release update branch.

    Note: The Pull Request should be created by a single developer.