How to troubleshoot an incorrect DeploymentWhen working with Copado, it may happen that a Git Promotion deployment didn’t go as expected. Some examples of issues you might encounter are:
Deployment completed with errors due to components not available in the target org or the "named in package.xml but not found in Zipped directory" error.
Deployment completed successfully but some components, profile permissions or code was not deployed or deployed incorrectly.
This article contains information that will help you understand what is causing that behaviour.
In order to perform a deployment to a Salesforce org, you need a Zipped file. This Zipped file contains a package.xml file and some other files with the content you want to deploy.
The package.xml has the list of components and its created from the selections in the deployment which are the components committed in the user stories.
The rest of the files in the zipped directory will be created from the data in the .xml files in the Promotion Branch in Git.
This means that the content you are deploying is taken from the promotion branch created in Git for that particular deployment. You will find the promotion branch name by navigating to the deployment record and clicking in the deployment step name.
The promotion branch is created when the deployment step is created. It is created from the target branch and the feature branches of the user stories included in this deployment are merged into it.
Copado will take the content to be deployed from that specific promotion branch so, whatever was deployed, or Copado tried to deploy was taken from that promotion branch.
Now that you know the promotion branch name and you know that we are taking the content of your deployment from there, how can you find that promotion branch in Git?
Navigate to your Git repository and search for that specific branch or click on the promotion branch name if you are on Copado v12. The screenshots below belongs to Github but the process is similar in BitBucket, GitLab or VSTS.
Once you are in the promotion branch, you can navigate to the specific file you are having problems with and check if the behaviour you saw in the deployment makes sense with the content of your promotion branch. For example:
Deployment errors due to components not available in the target org.
If the component doesn’t exist in your promotion branch and the component doesn’t exist in the target org, the error is expected since the component is required by Salesforce in the target org but it’s not being deployed.
Component named in package.xml but not found in Zipped directory.
If the component exist in the list of components in your deployment record but the component doesn’t exist in your promotion branch, the error is expected since the component will be listed in the package.xml file but it’s not included in the zipped directory because it doesn’t exist in the promotion brach.
Components or profile permissions not deployed properly.
If the component or profile permission exist in the promotion branch in the same way it was deployed, the deployment behaviour is expected. Some examples:
User Permission set to true in the promotion branch is deployed as true in the target org.
FLS not included in the profile xml file in the promotion branch will not be deployed neither true or false.
Code not deployed or not deployed properly.
After checking the promotion branch in Git for that deployment, you will see that the behaviour in the deployment is expected based on the content in the promotion branch. The problem now most likely, is that the content of the promotion branch is not what you expected.
How did that content end up in the promotion branch? In order to answer this question we will have to do some more troubleshooting.
The promotion branch you are looking at is the result of merging the feature branches of the user stories into the promotion branch that was created from the target branch.
Let’s focus on the feature branch:
Navigate to the user story where the affected component was committed. From the user story, click on the feature branch link or search in Git for the feature branch name.
Once in the feature branch, check if the content you are expecting to be in the promotion branch, exist in the feature branch.
If it doesn’t exist, that explains why it was not merged into the promotion branch. If it doesn’t exist in the promotion branch, it will not be deployed. The investigation is completed.
If it does exist but it’s incorrect (it’s the same as in the promotion branch) that explains all. The incorrect content in the feature branch was merged into the promotion branch. The investigation is completed.
If it does exist, and the content is correct, it’s important to know if:
- The content exist as part of the commit. There was a modification in that piece of code, FLS, field, etc when the commit in the user story was done.
- The content exist but not as part of the commit. The content was already there when the component was committed and the commit process didn’t make any modification. This means that the content already existed in the feature branch and this one is created from master therefore the content already exist in master.
You already know how to navigate to the promotion branch in Git. Check the history of commits for that promotion branch. You should check the history of commits from the root folder of the branch, not from a specific file. You can see if there was a conflict or not when merging the feature branch and which files were affected.
If there wasn’t any conflict resolution in the affected file, it means that Git performed the merge without Copado intervention.
If there is a message of Copado auto resolving, check the files that were merged with Copado intervention to see if the affected file is one of them.
In this article “Conflict Resolution with Git Integration” you will see the way Copado auto resolve based on the component type. There are 2 main auto resolve types, “semantic merge” and “A will win over B”.
Now that you know the content of the feature branch, if there was a conflict or not in the affected file when merging the branches and the type of conflict resolution that Copado applies for that component, check the table below. You should get an explanation for the content you are seeing in the promotion branch.
|Auto Resolve||No Auto resolve|
Semantic MergeAuto Resolve on files listed here.
A will win over B
Rest of the files.
|Merge is done without Copado intervention.|
|Content was committed on feature branch.||When doing the semantic merge, we should include in the promotion branch the content related to the components committed in the user story.|
If that is not the case, there might be an issue with the auto resolve.
|You should have in the promotion branch the same as you have in the feature branch since the content in the promotion was overridden with the content in the feature.||The result of this merge is based on the status of the branches, commit history and the git logic.|
If the content was added in the commit, it should have been merged unless the commit Id already exist in the target branch.
See scenario #2 here.
|Content already existed on feature branch.||When doing the semantic merge, we should include in the promotion branch the content related to the components committed in the user story.|
If that is not the case, there might be an issue with the auto resolve.
|You should have in the promotion branch the same as you have in the feature branch since the content in the promotion was overridden with the content in the feature.||The result of this merge is based on the status of the branches and the git logic.|
If the content was not added in the commit, Git might understand that it doesn’t have to be added to the promotion branch since it wasn’t added in the feature branch. (It already existed)
See scenario #1 here.