[SalesForce] Deploy sfdx project to another sandbox with CI

SFDX project folder structure is little different from previous folder structure where all metadata folders are inside src folder.

ANT agent on our Continuous Integration tool works for the old folder structure. How can I make the agent work for the new folder structure?

1) Convert SFDX to src folder structure and commit to VCS

2) Update CI script to read SFDX project and deploy to sandboxes(dev, uat, prod etc)

Any examples to the recommended approach is appreciated. Thanks!

Best Answer

At very high level here are the steps you need to take to convert the existing source format to the DX source format .

1.Replace your ANT Migration tooling to leverage SalesforceDX CLI .Assuming your CI is a unix server you can run below to install

wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz

mkdir sfdx

tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1

./sfdx/install

or If you have node(Ensure that Node v8.6.0 or later is installed on your computer) and npm installed on the CI server use below

npm install sfdx-cli --global

Convert your existing project source code to the DX Source format using the technique described here

3.The source in your SVN will be of DX format .Use the metadata convert command to convert the source to metadata format that you can deploy

sfdx force:source:convert -r path/to/source -d path/to/outputdir

4.Authenticate to the org where you want to deploy using the sfdx auth command

You can use any approach mentioned in the doc other than web login to authenticate your CI server

4.Deploy the source using mdapi deploy command

sfdx force:mdapi:deploy -u <alias> -w 10 -d path/of/outputdir

Terminology

Also, there is a difference in terminology to pay attention to:

"Source form" is what most people will store in version control, this is what sfdx uses to push/pull from a scratch org. This is the form where you can put things into almost any folder that you want.
"Metadata API form" is the traditional form of code/objects/validation/etc..., and is what the Metadata API uses. The layout and structure of this code is more strict.

General flow

The general sfdx flow from a scratch org into a sandbox or production org is:

Convert from source form to metadata api form
- sfdx force:source:convert -d <target directory>
Use the metadata api to deploy
- sfdx force:mdapi:deploy -d <same directory as step 1> -u <username or alias>

+edit 2019-1-27

There is (and has been for a couple of releases, I think) a beta program that allows you to use force:source:push (and pull) with sandbox orgs. There's also an extension on the VSCode marketplace (also in beta at time of writing)

Aliases

Having an alias for your target org is nice, you can use sfdx force:org:list to enumerate the orgs that you've authorized sfdx to use. If the alias column isn't blank, you can use that alias for the -u parameter. Otherwise, you can simply use the username.

You can set an alias for an org by using the -a parameter for the sfdx force:auth commands. If you didn't do that, you can set an alias for an org that you've already authenticated with by using force:alias:set.

sfdx force:alias:set <alias to use>=<username>

If I have a "derek" sandbox, and my username for that sandbox is "derekf@mycompany.com.derek", setting an alias would be

sfdx force:alias:set derek=derekf@mycompany.com.derek

Other tips

If you're still worried about bricking prod, you can consider using sfdx force:mdapi:retrieve -k <path to your package.xml> -d <destination directory> -u <username or alias of your target org> to pull a copy of the files involved in your project from your production org prior to deploying your code.

Converting to metadata api form also generates a package.xml file. Using that should mean you retrieve the current production version of the things you're about to change. If things go south, you can simply do another deploy to restore the known-good version.

// pull the current metadata, and store in a "prodBackup" folder
sfdx force:mdapi:retrieve -k deployPrepared/package.xml -r prodBackup -u production

// If things go poorly in a deployment, restore from backup
// the mdapi:retrieve gives you results in the metadata api form, so no need to convert
sfdx force:mdapi:deploy -d prodBackup -u production`

Also, in the past, if you were using changesets or the force.com migration tool (w/ANT) there was an option to do a "validate" or "check only" deployment, where only tests were run (even if all tests succeeded, the deployment would not actually deploy the changes).

SFDX allows you to do the same thing with the -c option

sfdx force:mdapi:deploy -c -d myDeploymentDirectory -u ProductionAlias

SFDX – Deploy from Sandbox to Production Org

As of Now

You can use sfdx force:source:deploy -l RunLocalTests ... to run tests. This will enable deploying source-formatted metadata directly to production.

Original Answer

As of Spring '19

force:source:deploy doesn't support deploying to production, as it always specifies to run no tests, and tests are required for deployment to production. You can either use unlocked packages force:package:install, or you can use force:source:convert followed by force:mdapi:deploy to deploy to production.

Note to future visitors: This feature may have been added after this answer was written. Be sure to check the documentation.