Your new tools can coexist with existing User Interface options. |
The Command Line Interface (CLI) for SFDX can be accessed via menu options in Visual Studio Code, or through the terminal, or through a Windows Command Prompt. So I'm going to use the CLI commands in the steps for the most clarity. And I'm assuming you've enabled the Dev Hub from your Production Org via the Setup options in the Salesforce UI.
Step 1
SFDX force:org:list
Shows which orgs you are connected. You want to connect to your sandbox orgs to manage your development lifecycle, for example: developer, integration, staging.
Step 2
SFDX force:auth:web:login -r https://test.salesforce.com -a orgAlias -s
Connect a sandbox where you will find and update source code and configuration.
Text in italics will need to be specified by you when you run, and should apply to your work.
-r is followed by the login URL for the org, using test subdomain for sandboxes and login subdomain for your Production org. Be very careful when connecting to Production, test changes before you deploy them, of course.
-a is followed by an alias you are giving to this org connection. Something like 'Dev' for a developer sandbox maybe? 'Int' for an integration sandbox. You see where I'm going here.
-s indicates that this should be the default org and username for your current work and is important to remember. You can also check the force:org:list to make sure you know which org you are working in at all times.
Step 3
SFDX force:mdapi:retrieve -p somePackage -r r### -u orgAlias -s
Bring code and configuration from your org down to your local computer in a package.xml file. Text in italics will need to be specified by you when you run, and should apply to your work.
-p is followed by a package name, either outbound change set or package defined inside a Salesforce org.
-r is followed by the directory name on your local computer where the package will be saved.
-u is followed by the alias for the connected org where your package/outbound change set was defined.
-s indicates a single package structure for the xml file.
The code and configuration should be defined in your existing org using either Setup>Package Manager to automatically include all dependencies and get a ton of related metadata or using Setup>Outbound Change Set just to get the specific code and/or metadata that is changing.
Packages are super helpful and can be pre-defined in Production so that it is easy to see the full extent of code and customization dependencies related to your custom features. These pre-defined packages carry over to sandboxes you create for super easy org management. Don't upload it, we just want the definition of what it contains, and we want to keep that open and changeable.
Creating and retrieving an outbound change set in the sandbox where you are starting development gives you a more manageable set of metadata and code, just the bits you need right now. Keep the change set open, don't define any deployment connections, we just want the definition of what it contains and we want to be able to add and remove if necessary.
And of course you can create code locally with commands like force:lightning:component:create and save or deploy those creations to your development sandbox for testing.
I should mention that these outbound change sets and in-org package definitions are all available with Workbench for retrieve and deploy as well, just in case your admins and devs love a familiar UI.
Step 4
Unzip
Using your favorite tools, unzip the "unpackaged.zip" file you just saved to your specified local directory. Maybe you use a favorite application for zipping and unzipping, maybe jar xf from the command prompt.
You can now work with this code and configuration in any local app you choose, maybe VS Code. Make sure to save your changes back to your sandbox org. Run automated tests in the org using your favorite tools, check out Setup>Custom Code>Execute Tests.
Step 5
Backup with version control
Save to your favorite repository for backup and version control. You can run git commands from the command prompt or you can literally just drag and drop with cloud-based interfaces for GitHub and BitBucket. You can also connect tools like VS Code to your repository to help you do this automatically.
Step 6
SFDX force:mdapi:deploy -c -d r### -u orgAlias -w 100 -l RunSpecifiedTests -r testa, testb
Deploy changes to the next sandbox as you move your work through the various lifecycle stages. Text in italics will need to be specified by you when you run, and should apply to your work.
-c optionally check the deployment before removing this flag and deploying for keeps.
-d is followed by the local directory name where you have your work and package file (hey, it was '-r' before, but now it is not). You can even do a quick retrieve from sandbox to make sure you are deploying the latest version you tested in the sandbox org.
-u is followed by the alias you have given to the destination org you set up previously. Not the org you made changes in and tested in, but the org you are deploying changes to for further testing.
-w is followed by a wait time and is used for especially long running deployments.
-l RunSpecifiedTests optionally lets you exclude long running or unrelated tests, otherwise expect all your tests to run in the destination org, even bulk tests. Combine this with the -r option below:
-r is followed by a list of test classes. Keep your bulk tests in their own classes and separate from unit tests so you don't have to run them during production deployments if you don't have to, for example.
Done. You can look at the Deployment Status right in the destination org, using Setup options you already know.
Four super helpful SFDX CLI commands can really get help you break down your development lifecycle and use new tools where they are most helpful while keeping all the familiar Saleforce UI options to support your orgs and your users and to maintain those valuable audit records for changes in your Enterprise org.
No comments:
Post a Comment