After going back through all my commits and using the .forceignore file to exclude certain types of files, I found that the problem was with some static resources. I rebuilt the static resources from the state of the commit, redeployed, and everything worked.
Although I'm not 100% sure, it seems to have been some dependency issue that wasn't showing a helpful error.
There are different types of hurdles you will need to overcome to deploy to a scratch org. The same issues apply if you're trying to deploy to a developer org (not developer sandbox), but scratch orgs allow you to overcome some of them.
From easiest to hardest:
- Org Edition and Features
- Org Settings
- Org-Specific Metadata
- Org-Specific Limits
- Known Issues
Org Edition/Features
Some metadata can only be deployed to orgs with specific features enabled. For example, the CurrencyIsoCode
fields can only be deployed if the MultiCurrency
feature is enabled during scratch org creation.
You need to identify which features to enable in your scratch org definition file.
Org Settings
Some metadata can only be deployed to orgs when other metadata has specific values. For example, Case.SourceId
can only be deployed if the IsLiveAgentEnabled
setting is enabled.
These settings are stored as metadata so you can store them under version control. You can also deploy them to an org so you can adjust them while troubleshooting deployment errors. (Although some settings can't be changed through the metadata API, or can't be disabled once enabled.)
sfdx force:org:create
supports setting some of the org settings so you can update your scratch org definition file once you figure out which settings you need enabled.
Org-Specific Metadata
Some metadata can be tied to data in an org. You'll want to try to break these dependencies by updating your metadata.
For example, Workflow alerts can reference Users. Since these Users won't exist in the scratch org, you will probably want to update these to use Groups or Roles, which are stored as metadata, instead.
Custom Org Limits
You might have non-standard limits available in your production org such as an increased number of Sharing Rules allowed. This will have to be addressed through the new Org Shape functionality.
Known Issues and Bugs
There's at least one known issue related to history tracking that will might prevent deploying the metadata from a large production org to a scratch org for the time being.
If you run into other errors, check the known issues and report them.
Best Answer
Well, the sfdx command that you included in your comment is the correct one to use. If you're worried about messing up your production environment, why not use sfdx to deploy to a sandbox first?
Any sandbox will work, but using a full copy or partial copy sandbox would make it easier because you'd have some amount of "real" data that you could play around with to make sure, for example, that you haven't broken any customizations to
Opportunity
.Terminology
Also, there is a difference in terminology to pay attention to:
General flow
The general sfdx flow from a scratch org into a sandbox or production org is:
sfdx force:source:convert -d <target directory>
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 thesfdx force:auth
commands. If you didn't do that, you can set an alias for an org that you've already authenticated with by usingforce: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.
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