Changes in feature branch not merged in promotion branchWhen working with user stories and Git you might notice that a component that is present in the feature branch is not being merged into the promotion branch and therefore it's not deployed. Although this not likely to happen, there could be 2 scenarios that could lead to that situation.
1. The component exist in the feature branch but not as a change.
Let’s suppose you are working with the deployment flow below:
Dev >>> UAT >>> Prod
You need to remove the piece of code “Line3” in the class below in Dev environment, UAT and Prod.
After removing “Line3” in Dev, the class is committed in the US-001. This is what you see in the commit in the feature branch:
The changes are promoted and deployed to UAT. The line that is removed in the feature branch is removed also in the promotion branch. When the deployment is deployed, this is how your class looks like now in Dev and UAT.
Now you realise that the line you removed must exist in the class and also the Line6 must be added. You stop the prmotion of the US-001, go back to Dev organization and add the Line3 and one extra Line6 to the class. This is your class now in Dev.
A new user story US-002 is created to move the new additions to UAT and Prod. The class is committed in the user story and this is how your commit in the new feature branch looks like:
You can see in the commit that the “Line6” and the “Line3” are there as expected but there is a difference between them. The "Line6" was added. The Line3 was already there because it was never deleted in the master branch. Remember that you only promoted and deployed the US-001 to UAT, never to Prod.
Because the “Line3” is not an addition in the feature branch, if you promote and deploy the user story US-002, the “Line3” will not be added to the promotion branch and therefore it won’t be deployed to UAT.
Only the additions or deletions in the feature branches are merged into the promotion unless there is a conflict during the merge that Git is not able to resolve and forces copado to auto resolve the merge by overriding the target with the source file. More information here.
If you make modifications in a component which is not up to date in master branch, you might run into this issue.
The way to proceed here would be to move the US-001 back to Dev environment from UAT and commit the new changes (the addition of “Line3” and “Line6”) in that user story so that the commit is done in the feature branch where the “Line3” was originally deleted. This way both lines will be added in the commit and merged into the promotion branch.
Another option is to set the Base Branch in the new user story as the UAT branch so that the commit is made in a feature branch created from UAT which doesn't contain the "Line3".
This is the exact scenario.
A new field in Dev org is committed in a feature branch and promoted on May-18 to UAT. This commit has its own unique Commit Id. The user story is moved from Dev to UAT, the feature branch is merged into the promotion branch and this one is merged into the UAT branch. Now the Commit Id that created that field exist in the commit history of the UAT branch.
Later, that field is removed somehow from the UAT branch. The field is no longer there but the Commit Id that created the field is still in the commit history of the UAT branch.
The user story that was used to move that field from Dev to UAT is now sent back to the Dev organization again in order to add some extra changes.
Now on May-29th, the user story with the same feature branch containing the same field (and the same Commit Id for that field) is moved again to UAT. The feature branch is merged into the promotion branch created from UAT which doesn't contain the field (it was deleted somehow) BUT it contains, in the commit history, the Commit Id that created that field initially back on May-18.
Because the exact same Commit Id already exist in the commit history of the promotion branch (created from the UAT branch), that specific field created with that Commit Id is not going to be merged. Git is detecting the same Commit Id and thinks it's not necessary to merge that field again. The field exist in the feature branch but is not being merged into the promotion branch. You can even see the field as a change looking at the Commit Id that added the field into the feature branch but it won't be merged into the promotion branch.
This kind of issue might happen when user stories are moved back after being promoted to higher environments.
Creating a pull request directly in Git between the feature branch and a test promotion branch cloned from UAT will show the same results that you see after promoting the user story.
In order to move that field, you will have to commit it again in a new user story so that a new Commit Id is generated which will allow the field to be merged into the promotion branch.