19

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.

Improve this question

5 Answers 5

Reset to default
12

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

Improve this answer
3
  • Thanks, I wonder if it's easier for you because you are developing a product, whereas we are maintaining and developing an existing org, with no clear distinction between internal products.
    – Pablo Gonzalez
    May 24, 2019 at 13:07
  • 1
    Hi @CommonCoreTawan, Could be, though our services team that works on custom code bases are also moving over. Probably a question of where the biggest pain is in your development; if it is not related to things that SFDX improves, I can understand you being reluctant to put effort into moving over to SFDX. But longer term it is probably where you should be.
    – Keith C
    May 24, 2019 at 13:21
  • 1
    I think that's an excellent point, DX doesn't solve any problems that we have at the moment. I won't go into details as to why that is the case, but factors are org and team size, etc.
    – Pablo Gonzalez
    May 24, 2019 at 13:54
6

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.

Improve this answer
1
  • You can use force:source:push against tracking orgs for incremental deployment, or force:mdapi:deploy to do a full or selective deploy to a non-tracking org. You can also blow away sfdx's local cache of tracking state to ensure you have a full deploy. That said, it shouldn't be a common need to force a full deploy anyway (we only found one case for it, being a git reset scenario that confuses sfdx).
    – Phil W
    May 24, 2019 at 19:15
4

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.

Improve this answer
4
  • So you install an unlocked package in your customers' orgs? Is it easy for internal devs/admins to maintain that after you walk away? (you stated you work in consultancy, so I take it your engagements are finite)
    – Pablo Gonzalez
    May 24, 2019 at 14:17
  • 3
    We use it in two ways: 1. For long-term projects, we may implement that with unlocked packaging for the customer: all on their dev hub and the code ends up being theirs. 2. We have some of our own packages that we distribute via unlocked packaging to do general plumbing jobs. 2 holds the risk of customer modifying our package and then it getting squashed in an upgrade, but it's all Apex and they typically don't
    – Aidan
    May 24, 2019 at 14:21
  • Note that it doesn't make you modularise your code, but does let you do so.
    – Phil W
    May 24, 2019 at 19:30
  • Fair point @PhilW, if you choose to modularise, it makes the boundaries between modules solid. On a technicality, if you have a lot of metadata, it does force some modularisation because it cannot process vast amounts of metadata in a single module.
    – Aidan
    May 25, 2019 at 6:25
4

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.

Improve this answer
3

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .