The set of SFDX source commands has grown to include (presently beta):

sfdx force:source:deploy

and that seems similar to the mdapi commands:

sfdx force:mdapi:deploy

What is different?

(In particular, it would be great to be able to directly deploy code in SFDX format to a namespace org used for managed package uploading without having to convert to MDAPI format first, but I assume that is still not possible)


The two commands are virtually identical, except that you can upload metadata in sfdx format instead of mdapi format. And yes, this includes deploying metadata and code to a namespace org used for managed package uploading (I use sfdx with my primary dev org, which has had a namespace for nearly a decade).

| improve this answer | |
  • OK, so "sfdx force:source:deploy" (when GA) will allow managed package developers to stick to SFDX format (and avoid the MDAPI convert), correct? – Keith C Nov 7 '18 at 14:32
  • @KeithC You can use force:source:deploy today, even on your packaging org. Usually, when Salesforce says "beta," they mean "it's a high quality feature with known limitations." I think the only limitation is deploying against production (you should use 2GP to deploy changes to production). – sfdcfox Nov 7 '18 at 14:41
  • @sfdcfox correct me if I'm wrong, but I think that force:mdapi:deploy has the advantage of allowing you to do a "verify" deployment (which means that you run unit tests but you don't actually push the code to the org). AFAIK that can't be done with force:source:deploy – mkorman Feb 19 '19 at 16:33
  • @mkorman Correct. force:source:deploy is meant to be a tool for development of applications, not pushing stuff to production. – sfdcfox Feb 19 '19 at 18:02
  • @sfdcfox understood. However, for me running tests is part of developing apps. To push stuff to production I use a managed package. It's a question of semantics I guess. Thanks! – mkorman Feb 20 '19 at 9:23

I’ve been playing with sfdx force:source:deploy today and I can see several things:

  • it’s possible to specify the package.xml manifest file as a parameter, which is a little bit better than when you go through sfdx mdapi (because you need to go through sfdx force:source:convert to convert sfdx source into mdapi format and this outputs whole sfdx project - without possibility to limit scope to certain items).
  • it has certain flaws - e.g. if you specify only one custom field in your manifest file - nevertheless it converts and deploys whole object
  • there is also sfdx force:source:delete which seem to be nice alternative for destructive change set (whatever is not tracked in git source gets deleted from an org)

Testing that further, finally I’m trying to set git-based deployments for sandbox based orgs, seem to be an interesting addition to previously available tools.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.