Hopefully this doesn’t across as a rant. I’m genuinely interesting in objective feedback as to what are the benefits of using DX.
I know all feedback is opinionated, but one thing is saying “devops is the future!”, another one is a proper explanation on how DX practices can impact productivity, ideally with real-world examples;I’m looking for the latter.
Here are the benefits as described in one of the many articles found online. Below are my team’s argument for each, and we want to be challenged:
Improves team development and collaboration
How? With the MDAPI and Github, we already have access to code review, static code analysis, etc.
Facilitates automated testing and continuous integration
Same, with Jenkins or the MDAPI I can run all tests when I want, or automated when I deploy anything to do org
Makes the release cycle more efficient and agile
How? By being able to reason about the org as several applications? The steps needed to retrieve, deploy, push to scratch org, merge in git, resolve conflicts, etc…don’t go away just because you are using a new framework.
Create an Org, then transfer all application source and metadata from GitHub into it
Why not create a developer sandbox? Sure, might take longer for long orgs.
A local development work-space is setup for the developer
It’ll never be truly local, local means in a scratch org, which is just a disconnected org. It’s no different from a sandbox or dev org in that sense. It’s only different in that it’s empty and I can easily push from source, but it’s not more local than a personal dev sandbox.
Use any tool to modify code (CLI, Vim, Sublime, Atom etc.)
Can this not be done without DX already? Eclipse, Sublime, Weklin, etc.
Yes development could be done before. But it took discipline to get the code in version control consistent with the code in orgs. In SFDX version control is the “source of truth”.
Subjectively, SFDX is less frustrating to work in and more productive. We now have our Jenkins builds using new scratch orgs rather than recycled developer edition orgs and are pretty much using a scratch org per branch per developer. As we develop managed packages, being able to develop in an org that has the namespace set helps (in most but not all cases), saving a lot of hassle (e.g. only discovering namespace bugs after packaging). Packaging2 will be based on the SFDX format. The “push” model of transferring code to the org works pretty well (including the propagation of deletes); having the fields separated out makes sense; having zipped static resources unzipped makes sense. And the VSCode tooling is pretty good as is the Illuminated Cloud tooling and the SFDX format is where the tooling investment is going to be in the future.
But yes, SFDX doesn’t fix everything e.g. the inherent slowness of remote execution and the very poor debugging tools remain a frustration.
Personally, I would hate to go back, and the move over wasn’t too painful.
(The hardest part, if you already have version history, is to preserve that history when you transform your projects into the new format. We burned quite a lot of AWS time doing that conversion, and one of our engineers had to learn quite a bit more about Git than most people ever need to know to lead that work.)