Odapoc

What is Copado?. It’s a series of online tutorials that teach you how to implement the Salesforce Dev-Ops process. It’s a scalable Salesforce-native platform that provides value in every stage of the Salesforce DevOps process. It’s a new IT management methodology. It is an end-to-end, low-code DevOps platform to manage the Software delivery lifecycle for Salesforce and other SaaS Applications.

Which is NOT TRUE about Copado’s integration with version control?. It requires extensive knowledge of Git. With Git, all changes are tracked. Users with little knowledge of Git can leverage it.

Copado provides a conflict resolution engine that auto resolves Git conflicts in components. True. False.

How can Copado help you manage your releases in an agile way? Select all that apply (2 options). It enables you to work with different Agile frameworks. It offers an application called Copado Agile Management. It implements the agile planning and DevOps processes. It supports integrations with external ALM systems.

Which is TRUE about user stories?. User Stories establish a direct relationship between a change and its functional requirement. Only admin users can delete user story records. They can be assigned to multiple developers.

How does Copado solve the lack of compliance?. It sends users a list of all the changes so that they can review them and identify the ones that are non-compliant. It includes a compliance hub tool that allows you to scan all the metadata changes made in your environments in order to find security breaches.

What quality checking options does Copado offer out of the box?. Validating Changes. Static Code Analysis. Customization of the minimum apex coverage required. All of the above.

Which of the following statement is true about Copado Robotic Testing?. It is built on virtual robots that automate end-to-end software testing in minutes. It completely eliminates human intervention. It is low and pro-code user friendly. All of the above.

Dave has been working in the DEV 1 environment. Can you list the actions that will occur when Dave commits his changes in a User Story?. A Feature branch is created out of the Destination branch. The Feature branch is merged into the dev1 branch. The Feature branch is created out of master. The Feature branch is merged into the Destination branch. A Feature branch is created out of the master branch. The Feature branch is merged into the dev1 branch.

Rob has created a Promotion to include the team’s User Stories planned for the Release. Once he has created the promotion, the Business asks him to exclude some features from the Release. What should Rob do in this case?. Remove the commits related to those features from the Promotion branch. Delete the Feature branches related to those features. Deselect the User Stories related to those features and submit a new Deployment.

Which of the following is NOT an advantage of Copado's Branching Strategy?. It’s more flexible, as it allows the developed features to be isolated as long as they need to be. You can link every change to a User Story so that you can document your changes with accuracy. It eliminates manual work, since it automates the creation of feature branches and the merge process. It creates only one Release branch, so it reduces the number of branches in your repository.

When Dave’s User Story is deployed to Production environment, Copado reuses the same Feature branches that were created when he committed in Dev 1 environment. True. False.

Ana the admin created a new external id field for the account object. When she tried to commit from the user story commit page, she was unable to locate the field on the metadata grid. What should Ana do?. Ana should commit again from the correct user story. Ana should use the metadata filter to show only custom fields. Ana should refresh the Metadata Index.

Ana added a new field to the account object in her sandbox. After refreshing the metadata index from the commit changes page, the field is not showing on the grid. What could have gone wrong?. Ana did not commit the correct field. Ana was committing from a user story with an Org Credential different than the one for her sandbox. Ana did not refresh the metadata index.

Ana added a new field to the account layout in her sandbox. After committing the account layout, the user story displayed a message indicating that the last commit had no changes. What could be the problem?. Ana marked the account layout as "Retrieve Only" on the metadata grid. Ana committed from the incorrect user story. The metadata Index was not refreshed.

After committing the account layout, the user story shows a message indicating the last commit has no changes. What could be the problem?. The account layout on the source org had no differences regarding the feature branch. The user selected the wrong component. The metadata index was not refreshed.

Ana has to update the Account layout assignment. She has included the Support profile and the Support Account Layout in the User Story selection, but after a successful promotion, the assignment has not been updated in destination. What should Ana check?. The Support profile and the Support Account Layout were selected in the same commit. The Support Account Layout exists in destination. The User Story status was set to Completed before promoting.

Ana has been asked to grant FLS to the field Account.Product_Amount__c for Sales Users. The field already exists in Production and she is not interested in committing any changes in the field. Which steps should Ana follow to commit the FLS?. Flag both the Sales Profile and the Account.Product_Amount__c CustomField as Selected. Flag the Sales Profile as Retrieve Only and the Account.Product_Amount__c CustomField as Selected. Flag the Sales Profile as Selected and the Account.Product_Amount__c CustomField as Retrieve Only. Flag the Sales Profile as Selected and the Account CustomObject as Retrieve Only.

Which is TRUE about the Retrieve Only feature?. Components selected as Retrieve Only will also be displayed in the metadata grid. Components selected as Retrieve Only are neither committed nor deployed. Components selected as Retrieve Only must exist in destination, otherwise the deployment will fail. All are correct.

Which is TRUE when using the Full Profile & Permission Sets Git Operation?. Active system permissions and all the references to the related components in the Profile are committed. If the Profile or Permission Set exists in the feature branch, only active permissions are committed. Active and disabled system permissions, and all the references to the related components in the Profile are committed.

Which is NOT true when using Promote and Deploy checkbox from a user story?. The promotion’s status is updated while the deployment is being executed. A deployment record is automatically created but the user needs to launch the deployment. You can only promote one user story at a time. A deployment record is automatically created and executed.

After trying to Promote and Deploy a user story with some changes in the Sales profile, Rob received an email notifying him that the promotion had failed. How can Rob review the deployment errors?. Navigate to the User Story Promotion record, open the related deployment and review the results in the failed deployment step. From the user story record, navigate to the deployment related list and review the Deployment Errors field. Navigate to the User Story Promotion record and from the Promotion error tab, click on view Deployment Errors. Open the user story record, and click on View Results.

There are five new user stories marked as Ready to Promote and ready to be promoted to the next environment. Rob has been asked to deploy all five from the dev1 environment to the UAT environment. What would be the best way to do this?. Create a promotion record, select the first approved user story and deploy the promotion. Then repeat the same process for the remaining four user stories. Use the Promote and Deploy option and deploy the user stories one by one. Create a promotion record, select the five approved user stories and deploy the promotion.

Ana has created a promotion and she’s not able to find a user story in the Available User Stories list. What should Ana check?. The user story “Ready to Promote” checkbox is flagged. The user story has commits. The user story status has been set to "Ready to Promote". The user story destination org credential is filled.

When is the promotion branch created?. Once the promotion record is created and its status is set to Completed. Once the user story record is marked as "Ready to Promote". Once the deployment record is launched. Once the deployment record is created.

What are the advantages of applying best practices in Mass Back Promotions?. Reduces time by back promoting all the User Stories in bulk. Reduces the possibility of getting into a merge conflict. It allows you to back promote the metadata changes without the inconvenience of sandboxes refresh. All are correct.

What are the risks Dave should consider before the daily Back Promotion process scheduled at 6 pm?. Uncommitted changes in the target branch are always overwritten. Uncommitted changes in the target environment may be overwritten. There are no risks when Back Promoting. None are correct.

Rob has to Mass Back Promote 6 tested User Stories from UAT to minimize differences between sandboxes. He has to Back Promote 1 to dev1, 3 to dev2 and 2 to dev3. How many Promotion records will be created when clicking on Create Back Promotion & Deploy?. 3, one per destination environment. 3, one per environment. 1, all User Stories in one record. 6, one for each User Story.