OK, let's start by saying that this is NOT the rulebook 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.
...
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 retrives 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).
...
- 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 paramenterparameter.
- Use the Alias for your production org that you authorised with DX
...
And if we go into Salesforce we see the failed Deployment there.
Now, fix the errors, itterateiterate, until you have a full package that will deploy with no erorrserrors.
- 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, when you look in your org, you will see a Deployment Succeded Succeeded and Quick Deploy
Now you can run
...