Saturday, January 19, 2019

Easy SFDX for Enterprise and Others

When cousin Tim Toady took the doorknob and lock apart on the back door after his key broke, he had a lot of trouble figuring out how to put it back together.  With a hundred tiny pieces laid out across the kitchen, Auntie Pat Tern sifted out a dozen of the most important, handed it to cousin Tim and told him to just use that for now.  Unsatisfied, Tim tried to put a few more parts back in, triggered the spring and the entire thing exploded across the kitchen again.That's when Auntie Pat Tern reminded him of two guiding principles: 1) Keep It So Simple and 2) Keep track of all your changes.  He could have taped each piece to a sheet of paper, in order, as he dismantled the lock, for example.

That reminded me of the guiding principles behind implementing Salesforce Developer Experience for the Enterprise Org.  Staying Agile means finding the Minimum Viable Product for tools you implement, not just products you build, so here is my guide to easy SFDX for the Enterprise. (See part 2 of this post for the actual commands.)


1. Discover:  A little reading reveals that SFDX is intended to "enable source-driven development, team collaboration with governance, and new levels of agility".  To accomplish this, it offers the important benefit of using "developer tools you already know." Use what you know, that's easy.

One thing we know in our Enterprise orgs is that configuration changes may happen in Production to meet immediate release requirements.  So the Production org itself is always the absolute source of truth for the org.  You can't just implement source control and claim that the source of truth is there because the bugs your users report will be found in Production and hopefully easily reproduced in Sandbox, that easily created org copy that is a developer tool you already know.

So the first step is to use the developer tools you already know: Production is source of truth for code and metadata and Sandboxes provide great individual and team test environments.  Keep them all. Use Dev Hub in Production to enable command line logins to these orgs.

2. Develop: SFDX includes a Command Line Interface (CLI) that lets you connect to your Enterprise Production org as well as your Sandboxes using simple and batchable commands. That gives you the power to make use of local tools, including local code editing and version control by connecting the CLI to your orgs and pulling down the code to edit locally.

Different Developer Sandboxes and different bits of code on the local computer make keeping track of all the versions and making sure they are merged and integrated into the larger system for testing means that version control is more important than ever.

For version control, we use Git on the local computer and cloud-based systems like GitHub for team backups and version control. Our local git directory can be connected to our own personal branch (or maybe to a feature branch) of the org repository in GitHub. Following tech review, developer branches can be merged into the main code branch. And this can be automated so that a developer's work gets backed up from their local computers to the cloud repo on a regular basis.

You already know about backups and version control if you use something like Microsoft Word.  It periodically auto-saves the working version of your documents. If your computer crashes, you have a choice between loading a version you saved or a version that Word automatically saved.  Version control to the rescue!  That can definitely be useful when you are doing Test Driven Development and your test fails because of your last set of changes and you decide to roll those back to the previous successful version.

If you use Git for version control of your work on your computer, you can keep track of versions.  And you can post those versions to GitHub, BitBucket or similar.  These tools can make team collaboration easier with everyone checking their latest working version into the repository in the cloud. It's like the difference between Word on your local computer and Quip Documents in the cloud.  Collaboration can be simplified with cloud solutions. And you can create a process for branches that get merged into a single main repository based on your own team's organization.

We have different repositories for different platforms we develop on.  And developers are free to create their own repositories for their own organization as well.  One developer keeps every feature in separate branches and another developer keeps just a local repo and a cloud repo, no branches. For our org-wide repository, we have branches based on releases so that short-term and long-term projects are kept separate.

The CLI adds flexibility to our Development Cycle by letting individuals choose tools they are familiar with and develop code locally or continue to develop in the Dev Console even, either way we can create a single shared backup and version control repository of everyone's work thanks to simple CLI commands.

3. Retrieve and Deploy: Following our SFDX process of using what you already know, we can easily coordinate the efforts of admins who make configuration changes in Sandbox into our version control as well as developers who want to edit code with apps they run on their own computer.  Salesforce provides two easy tools to work with the CLI: Packages and Outbound Change Sets.  If you haven't tried both, take a look in Setup>Home for them.

Packages give you the chance to define related sets of custom code and custom configuration metadata. Choose a bit of code and dependency data like custom objects and fields are automatically added. You can create Packages to look for overlap of functional dependencies in your org. And to help you document feature specifications.

Outbound Change Sets give you a bit more control to stick to only code and configuration that has immediately changed, and not include more stable code and configuration from prior development that is already in Production. You can use these to get the most up-to-date configuration changes on the fly from production for anything you need to work on.

Both Packages and Outbound Change Sets can be pulled out of the org and onto the local computer using the CLI retrieve command. These can also be deployed to any other org (yes, including Production) using the CLI deploy command.  Retrieve pulls down a Zip file including a package.xml defining what has been retrieved and folders of metadata, all the same for packages or change sets. You can unzip this into your local Git directory to update your version and you can use the CLI to deploy back to any org after you've made changes. In between, backup ongoing work to shared repositories to merge changes for the next stage of the development cycle.

Sticking with these familiar tools, we not only keep it simple, but we ensure that Admins and Devs can work well together because the org remains the source of truth and work efforts can be tracked, changes can be audited all in the org as usual.

4. Iterate: Since we have the ability to connect to our familiar Enterprise orgs as well as the ability to work on changes locally and use tools for searching and comparing code and configuration versions, we create a stronger collaboration.  Since we can use Git commands on our local computer to manage the backup and version control, we have even better insights along the development cycle, regardless of Sandbox refreshes.

With changes happening in a variety of orgs, local repositories may need to rebase if a branch gets too far our of sync. For Enterprise orgs, the source of truth is what your users see when they report bugs and praise new features. So bringing your local repository back into sync with upstream changes is simplified.

If you have separate repositories for each development stage from Integration to UAT, Staging, and Production, developers can retrieve changes at each point in the process. This makes it even easier to compare versions when a feature breaks after an upstream deployment.  Verifying whether the correct version was deployed with all of its component parts can be done locally, in shared repositories, and by auditing recent deployments right in the orgs.  And reverting to another version of a feature is even easier when you have backups in version control at each step.

Benefits of Change

SFDX helps Enterprise orgs follow Auntie Pat Tern's advice: Keep It So Simple and keep track of all your changes.  By allowing admins and devs both to work with tools most familiar to them, at the same time, SFDX offers greater insight and transparency into the development cycle. Because the CLI opens up opportunities to make use of tools like VS Code and online repositories, debugging throughout the release processes may be simplified as well.  And the CLI gives the power to make everything more automated for a more continuous integration of changes into each new environment at every stage of Enterprise development.

Ultimately, the best implementation of the Salesforce Developer Experience is to make use of what you know and implement it your way, just like the SFDX Developer Guide recommends. Give yourself even more power with command line deployment and retrieval of packages pre-defined in your orgs through easy and familiar Salesforce Setup options. Get even more peace of mind with backups at each stage of the release process thanks to the CLI and Git local repositories connected to shared repositories online.