The error indicates that the port is already in use. In order for a program to listen to a socket, it needs to bind to one of 65,635 ports. Only one copy of one program can use any particular port at one time. Odds are, a previous run started on the same port and never terminated, thus holding that port hostage. Try restarting your computer and then authorizing again. Otherwise, you might already have a program that runs on the default port (1717), in which case, you should create a new Connected App as outlined in Create a Connected App.
Log in to your Dev Hub org.
From Setup, enter App Manager in the Quick Find box to get to the Lightning Experience App Manager.
In the top-right corner, click New Connected App.
Update the basic information as needed, such as the connected app name and your email address.
Select Enable OAuth Settings.
For the callback URL, enter http://localhost:1717/OauthRedirect.
If port 1717 (the default) is already in use on your local machine, specify an available one instead. Make sure to also update your sfdx-project.json file by setting the oauthLocalPort property to the new port. For example, if you set the callback URL to http://localhost:1919/OauthRedirect:
"oauthLocalPort" : "1919"
(Note: Fixed a typo found in the original documentation)
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:
- "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
Best Answer
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.