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 Branch Management application.
- 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 Release Management page (Manage Branches page if you are in v11 or under) of the deployment flow to see if new changes in Integration can be synced into the dev sandbox.
- If a sync is available, review the file differences before syncing.
- When the user story is finished, scroll to the User Story Metadata related list to see if there is a potential conflict with the user story metadata components. If there is a potential conflict:
- Check the user story metadata report to see in which user stories the same metadata components have been committed.
- Discuss the changes with the release manager and/or the owner(s) of the other user stories.
- Alternatively, compare the feature branches of the user stories in Git.
- If the other user stories are already in the higher environments (integration, UAT, prod), check that you have already synced any changes into the dev sandbox. If you have not synced the changes:
- Go to the Release Management page (Manage Branches page if you are in v11 or under) of the deployment flow and review the file differences to see if the new changes in integration conflict with the changes in your sandbox.
- Review with the release manager and the team members which changes should remain:
- Only the changes in integration.
- Only the new changes in the dev sandbox.
- The changes in integration plus the changes in the dev sandbox.
- Sync the new changes from integration. If the sync overwrites your changes, act according to the discussions with your release manager and team members. Recommit any modified components in the user story. Then promote and deploy as usual.
Phase 3: Promotions & Back 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.
As of Copado v9, 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 deployment flow of the selected project or release and will create a promotion into the selected destination.
User Stories Ahead and Behind
As of Copado v9, 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 Changes 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.
In order to display user stories ahead and behind, click the toggle to the left of the flow bar.