Test information

| 1ckv24ngoj | CBM + CCM Release Process | | "In this article, you will find the best practices for the release process with Copado Branch Management and Copado Change Management. Phase 1: Initial Setup and Training. Set up the User Story Metadata Index feature. Create a user story metadata report and provide your team with permissions to access the report. Add the User Story Metadata related list in the user story layout.. Assign Branch Management permissions to the developers/admins in their corresponding development sandboxes. This is to grant these users permission to sync changes into their sandboxes with Copado.. Understand why Copado resolves Git conflicts: If you were to look into the Git repository of a Salesforce metadata, you will find XML files all around (except for a few folders like classes and triggers). As soon as you have multiple users making commits to different branches with shared XML-based files, you will start having git conflicts. This means that for every merge happening on your repository a conflict resolution has to be done. In real world scenarios, a Custom Object Profile may have thousands of git conflicts, therefore Git + Salesforce does not scale unless you have a tool that can automatically resolve those conflicts for you. Copado always tries first to do a native git merge, if that is not possible it will apply different strategies depending of the type of metadata and user story metadata selection.. Understand how Copado performs Git merges. Phase 2: User Stories in Development Environments. If a user story is currently located in a dev sandbox: Continually commit the metadata components that are ready. It is better to do regular commits with few components than committing many components at once.. Open daily the pipeline's Pipeline Manager page to see if new user stories in Integration can be back promoted into the dev sandbox. If a back promotion is available, back promote the user stories to the lower environments. Phase 3: Promotions & Back Promotions. Promotions. When the user story is promoted, Copado creates a promotion branch out of the destination branch. Then the feature branch(es) of the promoted user story(ies) get merged into the promotion branch, with the version of the files as in the feature branch(es), not the source org branch. If you are promoting multiple user stories, feature branches get merged in ascending order based on the user story number. If there are overlapped metadata (e.g. 2 or more user stories contain the same Apex Class). Copado will try first a Git merge, but if there is a Git conflict, the feature branch version of the file will win over the promotion branch. This could lead to the last user story overwriting other user stories in the same promotion. This situation can be detected in advance with the overlap awareness feature. If Copado auto-resolves conflicts, you will receive an email with the file name(s) where the conflicts were auto-resolved. You can also review the merge in the promotion branch in the Git repository. You then need to sync the feature branches so that they have the same version of the overlapped file. For example, if you're promoting from UAT to prod, and User Story 1 and User Story 2 contain class A: Go to User Story 1, click on Commit Files and commit Class A. Repeat this process for User Story 2. Now both feature branches contain the same version of Class A, as it is in the UAT environment. Create a new promotion deployment, now Class A will contain the intended content in the promotion branch. Back Promotions. You can promote user stories from higher environments back to lower environments by creating a back promotion. When creating a new promotion from the Promotion tab, a Back Promotion checkbox will be shown. When checked, the Source Environment field switches to Destination Environment. Copado will infer the source environment based on the pipeline of the selected project or release and will create a promotion into the selected destination. User Stories Ahead and Behind. The User Story page is provided with user stories ahead and behind information within the flow bar: User Stories Ahead: User stories sitting in the current environment with Promote Change enabled that have not been promoted and deployed to the next environment.. User Stories Behind: User stories promoted to the next environment through a different stream of work that has not been back promoted to the environment of the current user story being displayed. .. User stories will be considered ahead of the next environment as soon as you enable the Promote Change checkbox." | "

In this article