2

Currently we are following ChangeSet deployment model and want to switch to Org deployment model to support CI/CD process by taking advantage of Salesforce CLI commands.

But, for deployment to Orgs there are mainly two commands provided by salesforce.

  1. sfdx force:source:deploy -- Deploys in source format to an org.

  2. sfdx force:mdapi:deploy -- Deploys in metadata format to an org.

Among these, which command should be used during automated deployments ?

I got really confused after reading this post from Trailhead. Below is that section from Trailhead

Why Should I Use mdapi:deploy to Deploy My Changes from This Point Forward? The force:source:deploy command is meant for development use cases when you are interacting with a sandbox for development and local testing. The command is not transactional and attempts to deploy all components. If any change in your project has errors but other changes are valid, the command deploys all changes that are valid and compile. Those changes that can’t compile are not deployed, but the overall command completes successfully.

Instead use the Salesforce CLI force:mdapi:deploy command to perform integration testing and staging, and then deployment to production. If any component has errors, the command rolls back the entire deployment. This transactional process maintains the integrity of your staging and production environments.

Any suggestion on this will be really helpful.

2
  • 1
    in short words, if metadata in sfdx format (folders, sub-folders, force-app folder), use force:source:deploy (I personally prefer this format, much easier to merge conflicts), if your metadata in the repo in a classic format (like big Case.object file with fields, list views etc), use force:mdapi:deploy Jun 29, 2021 at 8:09
  • @OleksandrBerehovskyi we are saving metadata in sfdx format in repo. So are you recommending force:source:deploy ? Also, what is you comments on the Saleforce recommendation from Trailhead that I have mentioned above.
    – jeninjames
    Jun 29, 2021 at 8:17

2 Answers 2

1

Despite several advantages of force:source:deploy, I'd recommend to use MD API, since its mature and has more coverage. And there are many way to invoke the same(ANT, Workbench etc) and we don't need to worry on the legacy metadata to broke.

Try to start using scratch org and once your all metadata api is available with MD API, then move to force:source:deploy. To convert your scratch org folder structure in mdapi format you can use force:source:convert so that your pipeline would be stable and you don't need to worry on different structure itself.

You can check all the coverage's here - https://developer.salesforce.com/docs/metadata-coverage/52

1

sfdx force:source:deploy and sfdx force:mdapi:deploy are not really different from each other except for the metadata format they support.

As time passes SFDX is more and more supported and Salesforce is really investing in that direction rather than MDAPI. Just compare the coverage for source (DX) format between API 52.0 and 55.0 - https://developer.salesforce.com/docs/metadata-coverage/55 By the way, I don't think it is 100% accurate as it indicates for example Sharing Rules as not supported while I am having it in my repo and successfully deploying using DX format.

Don't convert between DX and MDAPI until you really need to. Stay with the format you have in the repository, preferably source format as it is easier to work with it (especially during pull request review).

The command is not transactional and attempts to deploy all components. If any change in your project has errors but other changes are valid, the command deploys all changes that are valid and compile. Those changes that can’t compile are not deployed, but the overall command completes successfully.

I don't think it is valid anymore. The source deployment has an option to rollback on error same as MDAPI deployment. You can verify that in Workbench by passing DeploymentID. I have been using that for over 2 years in multiple projects. When deploying to any org, Production included, when the error occurred it didn't do any partial deployment.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .