CBM + CCM Release Process

Updated 11 months ago by Iván Minaya

The best practices for the Release Process with Copado Branch Management and Copado Change Management is as follows:

Phase 1: Initial Setup and Training

  1. Setup the User Story Index Metadata feature
    • Create the 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.
  2. Assign Branch Management Permissions to the developers/admins in their corresponding development sandboxes. 
    • This is so that these users have permission to Sync changes into their sandboxes with the Branch Management application.
  3. Understand why Copado resolves git conflicts:
  4. 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.
    4. Understand how Copado performs Git merges.

Phase 2: User Stories In Development Environments

If a user story is currently located in a Dev Sandbox:

  1. Continually commit the metadata components that are ready. 
    • It is better to do regular commits with few components than committing many components at once.
  2. Open daily the Manage Branches page of the Deployment Flow to see if new changes in Integration can be synced into the Dev Sandbox.
  3. 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:
    • Visit 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 Manage Branches page 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 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 accordingly 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 target branch. Then the feature branch(es) of the promoted user story(es) get merged into the promotion branch, with the version of the files as in the feature branch(es), not the source org branch. 

If promoting multiple user stories, the 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 overlap awareness feature. If Copado auto-resolves conflicts, you will receive an email with the file name(s) where the conflicts where 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 contains class A: 

  1. Go to User Story 1, press the “Commit Files” button and commit Class A, and repeat the same for User Story 2. Now both feature branches contain the same version of Class A, as it is in the UAT environment.
  2. Create a new Promotion deployment, now Class A will contain the intended content on the promotion branch.

Back Promotions:

  • As from Copado v9 you can promote user stories from the higher environments back to the 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 onto the selected destination.

      User Stories Ahead and Behind

As from Copado v9, the User Story page is provided with User Stories Ahead and Behind information within the Flow Bar:

  • User Stories Ahead: 
    • User Stories seating in the current Environment with "Promote Changes" Enabled, but that have not been Promoted & Deployed to the next environment.
  •  User Stories Behind:
    • User Stories Promoted to the next Environment through a different stream of work, that have 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 in the left side of the Flow Bar.

Note: User Stories are considered ahead from the next environment as soon you enable the "Promote Change" checkbox.

How did we do?