Commit & Deployment Processes in Multi-Cloud

Updated 3 months ago by Copado Solutions

If you have already completed the configuration steps and created your multi-cloud pipeline (see the Heroku Plugin Configuration Steps and MuleSoft Plugin Configuration Steps articles if you haven’t done this yet)), you can start creating your user stories to commit your changes and move them across your multi-cloud pipeline. This process works similarly in all clouds.

Let’s take a look at the step-by-step process:

  1. First of all, create a user story in Copado (select your local dev environment as the user story environment and the corresponding local dev credential):
    Heroku User Story record
  2. Then, use any sfdx copado:work:set command to configure that user story to work with the CLI (see the CLI Commands article for more information). When you use this command, Copado also creates the feature branch where the changes will be committed.
    Work on user stories diagram
  3. Next, use the git add and git commit commands to add the files you want to commit.
  4. Once the files are ready, use the sfdx copado:work:push command to commit the changes to the user story. Copado will display these files on the metadata grid on the user story and create the corresponding User Story Metadata records:
    User Story Metadata records
  5. Finally, use the sfdx copado:work:submit -d command to promote and deploy the user story.
    Deploy user stories diagram

Conflict Resolution Considerations

If there is a conflict, Copado automatically overrides the conflicting files, and whatever is carried in the promotion will prevail over what is in the destination.

If you don’t want Copado to apply this conflict resolution strategy and want to resolve conflicts manually, you need to edit the Function step in the promote and deploy automation templates and leave the merge_strategy parameter blank:

Merge strategy parameter

If you leave this parameter blank, the Function step fails, and you need to manually review the conflicts and merge the feature branches in the Git repository.

How did we do?