DX for Deployments

Owned by Jodie Miners
Last updated: Jul 16, 2019
5 min read

OK, let's start by saying that this is NOT the rule-book for how to do this properly, this is me, documenting what is working, and knowing I have a lot to learn. (Which is the same as every page on this Wiki, and the reason for a wiki rather than a blog). But if this helps one person avoid using Change Sets or having to learn ANT then it's worth it. 

Folders

This works best when you have what you want to deploy in one Folder. 

Create a folder under force-app and name it what you want to deploy - eg feature-mynewfeature

Copy ALL the metadata and folders required for just that feature, as if you were building a Change Set. Now, there is no functionality like dependencies in Change Sets (the only reasonably redeeming feature of Change Sets) so as you start to learn what is required, you may want to build a change set then use that to double check your folder has everything needed). 

Now, this works if you are going to create the folder and deploy right away. It is a terrible idea as soon as something changes and you need to update the folder. So this is where Packages helps, but I haven't got the gist of packages yet, but start with Bonny Hinners ideas on how to set all this up (see it seems that you have to do retrieves from packages in metadata format, and I don't want to stuff around with converting, but maybe I need to just get over it).  

The reason I like using a folder that I have created, rather than deploying directly from a package, is that I can then modify the folder easily without affecting the package. If something fails in my deployment, I can remove it from my deployment folder and try the deployment again. It's easier than trying to fix everything so you can deploy in one shot. 

This will be an iterative process, just as using Change Sets is, but once you do this once, you will NEVER want to use Change Sets again. I can guarantee it!

Change Sets Package.xml

If you have to use Change Sets, then here's a nice way to download the Change Set into a package.xml file

Commit

Commit to git before you deploy, just so you know what's what. 

Live

Authorise your Live org in DX. 

Download the same metadata as Sandbox from your production org. Commit that into a new repository before you deploy. 

Tip use File > New Window to have Sandbox and Prod open in VSCode. VSCode workspaces are not supported for DX yet. 

Deploy

Use this documentation https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_build_mdapi_production.htm

First do a check deploy and run tests

sfdx force:source:deploy --checkonly --sourcepath force-app --targetusername production-org --testlevel RunLocalTests
  • Note to use the folder you created to stick your hand-crafted set of metadata to deploy. Tip use right click, copy relative path to get the path to enter in the --sourcepath parameter. 
  • Use the Alias for your production org that you authorised with DX

What does it do... well it takes the Source format, converts it to Metadata format, zips it up, uploads it to Salesforce and starts a test deployment. WOW. Even ANT which is much easier than Change Sets requires you stuffing around with Zip files. 

Failure

Yep, it is going to fail. 

Yep, 3 components deployed and 3 failures. That's OK, I was just testing this one out. 

And if we go into Salesforce we see the failed Deployment there. 

Now, fix the errors, iterate, until you have a full package that will deploy with no errors. 

  • One error was related to the username with the .sandboxname on the end was trying to deploy, so that's something I would modify in VSCode. 
  • And this example is one of metadata that I would not deploy, I would manually re-create them in Production, just to double check everything works well in production. 
  • And of course, you don't deploy consumer keys and secrets. No! 

Now, for larger packages, the status will be updated every few seconds and all the errors will start appearing. It's up to you to try and cancel to fix those errors, or let it run until ALL the errors are displayed. I would let it run. I don't yet know how to get a list of errors that is formatted better than what is output. 

Then finally after many iterations there are no deployment errors...

And then the tests run, and then you start to see the test errors. 

1 test error is not bad (smile)

Then finally after fixing that, you get no test errors!

And you get a list of the test class coverage and which lines are not covered. 

Now, when you look in your org, you will see a Deployment Succeeded and Quick Deploy

Now you can run 

sfdx force:source:deploy --targetusername production-org --validateddeployrequestid jobID

and pasting in the jobID from the run

And then you have a completed deployment! YAY!

And now it's time to go in and do all the manual things like where you commented out formula fields because they had a >5000 char limit in prod and not in Sandbox etc. 

Commit

Commit your newly deployed metadata, just to tidy things up. 

Also it's a good idea to retrieve from live and commit that. 

Notes

Be wary of API version changes. I retrieved before an upgrade and tried to deploy after an upgrade, and the Flows metadata is all changed and caused me all sorts of issues. 

Downsides?

No more deployment fish!