Applying Service Updates¶

Related Pages¶

Service Update Apply Process¶


Figure 1.1 - Service Update Apply Process


Figure 1.2 - Service Update: Proactive Adoption

Prerequisites¶

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 build place¶

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 update.
Click on button "Service Update" in the buildplace view.
Select the target service update from the drop down.
Click on 'Apply' (Figure 2.1)


Figure 2.1 - Service Update Dialog Box

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 (eg: "21.1.5" as shown below).


Figure 2.2 - Repository Information card

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 3.1 - Git info dialog box

Provide below information to Update Analyzer GIT-Info dialog (Figure 3.1)
- 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 solution and the Target UPD refers to the update to be moved on to.
After entering Customer Solution repository URL, Master and Delivery Branch radio buttons get enabled. To apply a service update proactively select the option 'master' (Figure 3.2), to analyze the impacts for customizations in customer solution repository master branch. To apply a service update as a resolution for a critical issue, select the option 'Delivery Branch' to analyze impacts for customizations in a particular delivery branch. Since these are the steps to apply a service update as a proactive adoption, select the option 'master'.

Figure 3.2 - Git info dialog box - customer solution repository branch selection
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 master 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.

Applying Service Update to Customer Solution repository¶

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

Clone Customer Solution repository

git clone <customer-solution-repo-url>
Change directory to the cloned folder.

cd customer-solution
Add Customer Baseline repository as an upstream to Customer Solution repository.

git remote add upstream <customer-baseline-repo-url>
Create and checkout a topic branch based on master branch.

git checkout -b <topic_branch_name>

e.g.: git checkout -b topic/piselk/ALE-01-ServiceUpdate,21.2

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.
Pull from upstream ( i.e. from Customer Baseline repository master branch)

git pull upstream master -X rename-threshold=95

Sometimes VI editor(Figure 4.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 4.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 5.1).

git diff

Figure 5.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 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 5.2). This output log should not contain any '<<<<<<< HEAD' tag.
Figure 5.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 master command, git terminal log should contain a warning message as mentioned below (Figure 6.1).

Figure 6.1 - Git terminal log message for merge conflicts

Therefore, follow these precautions to avoid merging the topic branch to master branch with merge conflicts.
- Identify if there are merge conflicts (Figure 6.2)
Figure 6.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 6.3).

git diff

Figure 6.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 6.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 6.5) by running git diff command, you are good to go.
git diff

Figure 6.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 6.6).
Figure 6.6 - Output when there are new changes and no merge conflicts

Move changes to the remote topic branch¶
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 7.1.
Figure 7.1 - Branch status when conflicts have been resolved
Test the changes using a topic environment.

Follow the below steps to Create the Pull Request¶
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
Create pull request to merge changes to Customer Solution repository master branch.

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. (Figure 8.1)

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.

Figure 8.1 - Pull Request merge branch

Follow the below steps to Merge the Pull Request¶
The next step is merging the topic branch to customer-solution repository master 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¶
Go to the buildpalce view 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.¶
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
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.

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 master branch, there can have situations were merge conflicts occur between the changes of service update topic branch and the new changes in the master branch added by parallel branches. ( i.e when your topic branch is not up-to-date with remote master ). In that case before merging the pull request, we advice you to follow the below steps.

Note: Do not rebase the topic branch with master 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 master branch for the local master branch to be up-to-date with remote master (Figure 10.2).

git pull origin master

Figure 10.2 - Git pull origin master

Resolve merge conflicts if exists. Then run the below commands.

git add . git commit -m "commit-message" git push origin <branch-name>

Now the pull request will be updated with the master 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 master branch with conflicts during the 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:¶
Go to the azure customer solution repository
Switch to the correct branch (master)
Go to the commit point where you want the repository reset back to (probably the point before the commit with merge conflicts)
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

Delivering a Service Update in a Corrective Delivery¶
- Follow the previous steps mentioned in this document
- Fetch the service update to the customer baseline repository
- Analyze the impact of the service update
- Apply the service update to the 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
- Add an upstream to Customer Solution repository pointing to Customer Baseline repository
git remote add upstream <customer-baseline-repo-url>
- 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> - Analyze the impact of the service update on the customer's use place.
- Provide the information to Update Analyzer GIT-Info dialog as in analyze the impact of a service update section mentioned in this document.
- In addition to the above information, after entering the Customer Solution Repository URL, click on the radio button 'Delivery Branch'. Delivery Branch dropdown will be populated with delivery branch names in the given Customer Solution Repository.
- Select the above checkout (delivery-tag-branch-name) Delivery Branch from the dropdown where the critical issue occurred.
- Once all input fields are filled in, click on the 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 the selected Delivery Branch of the Customer Solution Repository
- Once all three clones have been completed, click on the button 'Proceed Analysis' and perform update analysis.
- Pull from upstream (i.e. from Customer Baseline repository master branch)
git pull upstream master

Resolving conflicts when merging service update as a Corrective Delivery¶

If the git pull operation errors out due to conflicts, follow below steps to resolve the conflicts. - List down the files with conflicts

git status - Open the files with conflicts through an editor, look for the standard "<<<<<<< HEAD" marker and resolve the conflicts. - Once done, stage the files

git add - Verify the changes - Git commit and push local changes

git commit -m "meaningful commit message" git push origin refs/heads/<delivery-tag-branch-name>:refs/heads/<delivery-tag-branch-name>
- Order a delivery from the IFS Lifecycle Experience Portal to create a [corrective delivery](Ordering Deliveries - ALE Documentation For IFS Cloud for the service update.