Bsrgvty

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 saves 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.)

I find that DX is easier to work with. It doesn't depend on the developer knowing what/how to edit the package.xml file, for example (unless you are moving from the old format).

A huge gain, in my opinion, is that the pull and push commands seem to retrieve and deploy only the modified metadata (I might be wrong here). The old model retrieves and deploy everything instead, so DX should be faster than retrieving and deploying with the MDAPI (depending on what your setup is, an IDE plugin like Illuminated Cloud might be able to send a package.xml with just the metadata you want to retrieve or deploy too, but then again: you'd need an IDE and/or a plugin for that, whereas with DX you just need the CLI).

This isn't beneficial only to folks who work with managed packages, but Salesforce customers with big orgs and customizations as well. It feels great to be able to create a scratch org which is similar to production or QA in a few minutes, for example. Not only that, but be able to do this from within the CLI instead. This could also be a security gain, since a developer will not need access to production just to create a sandbox.

For me, there are three major advantages:

1. It makes you modularise your code

You might have your existing codebase working in what you conceive to be separate modules of functionality. But, once you split them up into DX packages, you can suddenly notice stray dependencies going where they shouldn't.

We all like to write well-engineered code, but have a tool to call you on it is really helpful.

2. It brings build processes to the masses

Yes, you can make yourself a nice process with Dev Sandboxes and automation tools. But many people working on SF can't invest the time in setting all that up. DX makes it a lot easier to get there. So, it's more attractive if you're not coming from a well-oiled existing process.

I work in a consultancy, so we don't have the time/budget to make a build process for all customers - only the ones whose complexity justifies it. DX lowers the bar for how difficult it is to do that, so we can do it for more customers.

3. Unlocked Packaging is way more flexible than old packaging

Packaging is really nice, and unlocked packaging gives us the freedom to: share a namespace between packages, remove items from a released package, etc. It generally means that you don't have to make irreversible commitments in your package design.

A really fundamental benefit is that you effectively guarantee that the org on which you develop is clean. You can't keep a scratch org longer than 30 days, so you can't treat it like a dev org. You can't build up cruft that isn't part of your version controlled source of truth that could cause problems for other developers without you quickly becoming aware) or affect the outcome of test executions.

This aspect alone makes it worthwhile.

The one disadvantage we see with our managed package development is the pull and push commands are MUCH slower than the mdapi selective equivalents because the client and server spend (for us) about 12 seconds just to determine what increment exists across our 6000+ components, so we find a push typically takes at least 14 seconds, usually more, compared with the selective deploy time of low 100s milliseconds with mdapi.

I wish I was using it more. I love the CLI. But it seems like every time I decided to really start a DX project -something goes wrong with my scratch org and I can never get all the metadata to push. Inevitably I get frustrated, give up, and use a Dev sandbox.