Copado Developer 100% PASS VERIFIED SOLUTIONS

Copado Developer 100% PASS VERIFIED SOLUTIONS Recommit Files A git operation that enables you re recommit components, remove components from User Story Selections, and re-create the user story feature branch Re-Create Feature Branch checkbox that appears when Recommit files is selected as the git operation. Used in cases where metadata was committed by mistake or is no longer needed in the user story. When checked, existing commits won't be present in the new feature branch and previous commit status will be 'Commit Not in Branch' *Ability to remove permissions to re-create feature branch via custom settings in setup. Custom settings→ personal settings→ manage→ disable RCFB in US* Recommit Files Flow: Re-Create Feature = FALSE 1. Commit the selected metadata components in the existing feature branch. 2. If the feature branch is not found because it was deleted manually in the Git Repository, Copado will automatically create a feature branch and commit the selected metadata. Recommit Files Flow: Re-Create Feature = TRUE 1. Delete the existing feature branch in the Git repository. 2. Create a new feature branch. 3. Commit the selected metadata components. Destructive Changes in Salesforce (w/o Copado) To delete SF components, a delete manifest file named destructiveC must be included that contains all components to be deleted. Also have to add an empty file that includes the API version in the same directory as the manifest. Deleting and Components in a Deployment (w/o Copado) Salesforce will return an error when a component is deleted that is being referenced somewhere else. -By default, deletions are processed before additions or updates. -If there are any dependencies between components, Salesforce allows you to perform both operations in a single deployment and define its order of execution by using the destructiveChangesP and destructiveChangesP. Destructive Changes One of the Git Operations that you can choose from the Commit Changes page that allows you to deploy component deletions Destructive Changes Flow (1) Copado will create a feature branch. The selected component will be deleted in the feature branch and then merged into the org's branch. (2) Copado will delete the entire file of the selected metadata in the org's branch if there is one. (3) If the selected components are referenced in other components, these references will also be deleted. (4) Deleted components flagged as Git Deletions in the User Story Selections and any other updated component if it was referencing the deleted component, flagged as Git Upserts. Destructive Changes Flow: Component Exists in Master Branch 1. A Git commit will be Completed successfully. 2. A feature branch carrying the deletion will be pushed to your repository. Destructive Changes Flow: Component DOES NOT Exists in Master Branch 1. A No Changes Git commit record will be created to the user story. 2. No feature branch will be pushed to the repository. NOTE: Copado allows you to enter a different base branch name to be used to generate the feature branch. Destructive Changes: Base Branch Decides where the feature branch is created from Destructive Changes: Credentials Lookup Field displayed after destructive changes is selected. If a different credential is selected in the lookup field, the metadata grid will display metadata indexed from the selected credential Destructive Changes: Add Row Button Used to find metadata that has already been deleted. User inputs API name and metadata type Git Conflict (Merge Conflict) When merging two branches that have the same files, but one or more lines in the files have been updated with different values in each branch. Git requires your help to determine which changes should be incorporated into the final merge. Copado Merge Order merge order of the User Stories into the Promotion branch is based on the User Story name field in ascending order. From Copado V12, you can override the default name order and define a custom merge order, based on a different user story field with asc or desc order. Two Types of Conflict Resolution Processes Automatic and Manual Automatic Conflict Resolution To save you the manual work of resolving the conflicted files, Copado provides you with the Auto Resolve feature. Depending on the type of file, Copado will apply a different auto-resolve conflict strategy. Manual Conflict Resolution Copado allows you to manually resolve file conflicts during the User Story promotion process with the Online Conflict Resolution feature. Components to Exclude from Auto Resolve ApexClass, ApexComponent, ApexPage, ApexTrigger and Layout Copado Auto-Resolve Default Behavior Copado will always attempt first to perform a Git merge, this means to integrate the content of the source branch into the destination branch. If conflicts are detected, Copado will take different approaches depending on the type of file. Copado Auto Resolve: Semantic Merge Copado detects differences in branch files so creates a third version of the file to bridge the gap between the other files Copado Auto Resolve: XML based Copado will do a semantic merge of the XML nodes if a conflict is found for the following metadata types. Profile PermissionSet WorkFlow CustomObject CustomLabels AssignmentRules Translations CustomObjectTranslation Copado Auto Resolve: StaticResources Whether the files are versioned or not within a Zip file, the result in case of conflict will be different. Using the Unzip option in the Git Snapshot (recommended for JavaScript and CSS): Copado will create a new Zip file with the merged content. Copado Auto Resolve: All other files (e.g ApexClasses, ApexTriggers, Layouts)File configuration in branch A will win over branch B. Meaning that the new changes override the existing content. Copado Auto Resolve: Review You can compare the file differences and review the merge by checking the pull request created by Copado. 1. Open the Promotion record and scroll down to the Deployments related list. 2. Click on Pull request. You'll be redirected to your Git repository, where you will be able to compare the file differences that caused the merge conflict. Online Conflict Resolution (manual) For specific and complex metadata types where identifying the right conflict resolution strategy is not a straightforward activity, Copado allows users to manually resolve file conflicts during the User Story promotion process, while User Story feature branches are merged into a promotion branch. If the Online Conflict Resolution feature is active and the conflicted files are of a supported type, Copado stops the merging process and uploads the conflicted files