Happy DXmas, Everyone! But What Is SalesforceDX?
Here’s a riddle that you probably *won’t* be finding in your Christmas Cracker this year: What’s the difference between traditional monolithic org development and modular artifact development? Tough question, right?! But let’s not get scared yet, first things first: Context.
In Summer ‘17 we got the beta release of Salesforce DX which was actually announced at Dreamforce 2016 for first time. And it’s now generally available from Winter ‘18.
The name literally means: Salesforce Developer Experience, and this product introduces a new model (set of tools & practices) to enhance team collaboration on development, which eases automated testing and continuous integration with the ultimate goal of making the release cycle more efficient and agile. And well you know how much I love agile…
The core principles that Salesforce has stuck to from inception to release of DX are as below. Most often these are seen as the core of modern software delivery:
- Everything is driven from source code
- Development is organized around team collaboration
- Environments are easily created and disposable
- Metadata and code is modular
- Development is based on open standards and extensibility
- Processes and tools facilitate continuous delivery
- Flexible packaging supports agile distribution model
Until DX, life developing in Salesforce looked something like this (what we call ‘monolithic’):
What now?
The idea is that with DX, rather than building code and customizations against an org you do it to an artifact (which is a representation of an org subset) so life is suddenly about modular artifacts, these groups of related things that can be developed in conjunction, separately tested and released independently of each other (which we call modular artifact development).
And the nature of DX really relies on a Version Control System (VCS) where the source of truth is maintained in a source control repository. And this gives you more flexibility in managing your teams and releases.
Key concepts:
You may have heard about CLI, the Salesforce Command Line Interface, which is sort of the center of DX. It’s a new tool, an interface for typing commands directly to the system which combines many capabilities from across several Salesforce APIs, like the Metadata API, as well as functionality from other tools like Force.com Migration and Workbench.
Another jargon word that comes to play on DX are the Scratch Orgs, a sort of naked simple and temporary org where you can push and pull source and metadata to and from your scratch org and run unit tests. This is much easier and quicker and you can use it for either and programmatic or declarative development, where you use and remove customizations without having to maintain more environments. In case you are wondering: Sandboxes are still in the game as destination of deployment, staging and UAT.
You create projects with one or multiple artifacts in a scratch org context, where you run your tests (or create a specific scratch org for tests of newly developed functionality). Once you are happy, commit your changes to the Version Control System, and before that you will easily be able to see the list of changes thanks to CLI, moving you away from having to embark on an epic quest for all details of what has been changed so that you only pull the relevant components that have changed.
In terms of continuous integration, one of Salesforce DX’s benefits is that you can work on whichever tool that may be already be in use by developers, and there has been a lot of effort on validation against most systems of continuous integration in the market.
Enough of theory, let’s check out some demos from the pilot program (if what you see seems too complicated, close your eyes and listen to the concepts):
Want to learn more? Start with Peter Chittum’s post on First Impressions with Salesforce DX and the Salesforce Developers site on all things DX.
Wishing you all a very merry DXmas!
