Copado Chapter 4 Exam Questions With 100%
Correct Answers.
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
-If the Recommit Files operation is selected, the metadata grid will automatically switch to the
Selected tab, displaying the components previously committed in the User Story.
-Can still navigate to the All Metadata tab and add new components to the US selections
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 destructiveChanges.xml must be included
that contains all components to be deleted. Also have to add an empty package.xml 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
destructiveChangesPre.xml and destructiveChangesPost.xml.
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.
Correct Answers.
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
-If the Recommit Files operation is selected, the metadata grid will automatically switch to the
Selected tab, displaying the components previously committed in the User Story.
-Can still navigate to the All Metadata tab and add new components to the US selections
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 destructiveChanges.xml must be included
that contains all components to be deleted. Also have to add an empty package.xml 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
destructiveChangesPre.xml and destructiveChangesPost.xml.
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.
