After going through the trailheads for sfdx, it sounds like for the actual deployment to a sandbox/production (assuming the CI for test and all are completed) for a DX project is:

  1. convert the source (which is in DX format) to metadata api format sfdx force:source:convert -d mdapioutput/

  2. deploy the converted metadata from #1 using the sfdx cli to a 'sandbox/prod'

sfdx force:mdapi:deploy -d mdapioutput/ -u MyTPO -w 100

The above command deploys to a sandbox with the alias 'MyTPO'

Is this the right way to deploy in DX (taking away the need for ant migration tool), if i am understanding it correctly? Please verify or share your experience. What about components like standard fields that are not supported by metadata api, are they supported in DX?

2 Answers 2


You can decide to publish your code from DX project using metadata API or creating a package. The details for deploying both ways can be found in this page.

TLDR: Yes, converting DX project to medatada API format and deploying it using mdapi:deploy is completely fine. Example for CI script:

#create conversion folder
mkdir [path/to/output/folder]

#convert to Metadata API format
sfdx force:source:convert -d [path/to/output/folder]

#login to sandbox
sfdx force:auth:jwt:grant --clientid $sandboxConsumerKey --username $sandboxUserName -a $sandboxName --jwtkeyfile assets/server.key -r https://test.salesforce.com

#deploy to sandbox
sfdx force:mdapi:deploy -d [path/to/output/folder] -u [sandboxName] -w 100

#remove conversion folder
rm -r -d mdapioutput

I only deployed to sandbox using this approach.

However, even though I did not try deploying using packages yet, I believe packaging approach is going to be the way to go when the second generation packaging is released.

  • i like the packaging idea too. But being new sf and there seem to be 2 groups: 1. ISV 2. Enterprise consumers. And packaging (atleast v1) seems to be speaking everything w.r.t ISV's. And we are not ISV. I kind of generate psuedo pacakge by using git tags
    – OK999
    Nov 21, 2017 at 15:26
  • but do you know if this kind of deployment works in Production? i havent tried it, and salesforce seems to have things that works in sandboxes but not in production
    – OK999
    Nov 22, 2017 at 18:30
  • I think it should because I found this in the docs: developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/… but I just tried with a sandbox so far. Nov 23, 2017 at 7:58

Looks good to me. The only thing I'd suggest is removing the Wait command if you find it isn't long enough and checking via deployment status, as makes it easier to deploy to multiple orgs where the package sizes/time to deploy mean waiting prevents you from deploying all in one shot.

i.e. if you want to push your package to multiple orgs, effectively asynchronously, then drop the wait and check in with each org separately.

Here's the batch file I used for one project that combines these commands:

@echo off
echo **XXX Package deployment**
REM This batch tool assumes that:
REM   - You have SFDX CLI set up (search on salesforce docs).
REM   - You have added the XXX orgs to your orgs:list using the CLI.
REM   - You have access to these orgs (show up in sfdx force:org:list as 'Connected').

sfdx force:source:convert -d mdapi_output_dir/ --packagename PACKAGENAME

REM Sites to deploy to sites.
sfdx force:mdapi:deploy -d mdapi_output_dir/ -u PBSLiveCopy -l RunSpecifiedTests -r GDPR_Org_Test

This works fine in VS Code to, via terminal. I've started committing these to my repos to got with the source code.

You must log in to answer this question.

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