Copado Branching Strategy

Updated 2 weeks ago by Miguel Carreras López

When a developer commits a change onto his/her User Story, Copado creates a feature branch for that User Story.

All the following commits in the same User Story will be collected in the feature branch.

This branch is taken out of master, so no "work in progress" or other features are carried on with this feature branch.

Then, each of the environments have their own branch (Org's branch), which are actually the ones monitored by our Branch Management App in order to evaluate the level of discrepancy between Orgs.

Everytime there is a User Story commit, Copado will merge that feature branch onto the Org's branch in which the developer was working, so we can keep the Org in sync with the metadata in the branch, besides you can monitor in the Branch Management App differences between the current stage and the following one, and the User Story feature branches get validated from both Git and Salesforce perspectives.

Now, when you are running a Promotion in Copado, Copado creates a Promotion Branch out of the destination's branch (this is known as "release branch" as well).

It is an exact copy of the destination onto which we are going to merge all User Stories included in the Promotion.

Doing this, we respect the original contents of destination while we add new contributions of developers to it; and we are going to check if the User Story feature branches can be merged all together.

If the merge has no conflicts or these are resolved automatically, then the deployment to destination takes place, and after the successful deployment, there is a final merge of the Promotion Branch onto destination Org's branch so User Story commits finally reach the following stage.

Here is the diagram:

How did we do?