It Really Is Time to Switch to DX

So my adventures in IDEs have stalled somewhat, but not because of the potential downtime involved. Im fact, we've just undergone a major change that incurred more downtime than simply switching an IDE would invoke, we switched development tool chains.

Until the launch of SalesforceDX there was only real way to handle development on the platform: you wrote code in a developer org or a sandbox, and then deployed code (sometimes via CI, sometimes manually) and other metadata to other instances, be it production or a packaging org. For the most part the main tool that's distributed as part of DX, the sfdx command line program, pushes code and metadata around, but it does so in a new format, and it interacts with other tools that are kept behind the scenes.

Not Just a Deployment Tool

You could argue that historically any IDE built for Salesforce is nothing more than a glorified deployment tool. Yes, they handle code completion, debug log based step through debuggingn etc., but in terms of getting code into an org they were hampered by the APIs available, i.e. the Tooling API and the Metadata API. The problem with these APIs is they're built around the idea of incremental changes, you can push new code, updates and deletes, but trying to do wholesale operations to change the state of an org is fraught with difficulty.

For example, like all developers (should do) you keep your code in a source control repository, and maybe you checkout a new branch and developer some new feature X, that involves the creation of a few new classes:

git checkout -b feature_X
// some coding later
git add ./src/classes/Xservices.class
git add ./src/classes/Xutils.class
git commit -m "Adds support for service x"

All well and good. The code is in your dev org and working perfectly so far although, you still need to add some extra functionality. So when an urgent request for feature Y crops up, you commit what you've done to source control, switch back to your develop (or master, or dave) branch and branch off again:

git checkout develop
git checkout -b feature_Y

Now here's the funky part, you start adding some new classes for feature Y, but the classes for X are still in your org. There's no easy, clean way to just replace what's in your org with your freshly-cut feature_Y branch. This is a pretty trivial example, and you may well be able to just delete the classes from feature X and plough on through, but once you've been working on the same code base for several years, your org can get messy. Very messy.

In my case, after three years of working in the same dev org, it had become quite different to the code kept in version control, with extra classes and fields all over the place. I didn't create a new one simply because our application can take a pretty heft amount of initial configuration and data loading, and I got pretty good at just working around the cruft and keeping a close eye on what was being merged into our main branch for packaging (yes, I issued pull requests myself). I did keep our packaging org clean through a CI tool chain, which definitely helped to mitigate any major issues. But why the past tense? Because we've moved on.

DX Makes Your Development Life Better

There's no two ways about this, the switch to DX has been game changing. Thanks to a certain @simongoodyear (that smiley chap everybody knows), we made the move to DX in the space of a week. He'd worked out just about all the things we needed in place, and now instead of having to spend half a day trying to sort out a new developer org (I only really did this previously for new developers) we can spin up a scratch org, with data loaded and the application configured, in a matter of minutes, with a single shell script.

The impact of this has been profound, and these are just some of the highlights:

• We now have a single repository containing code for our static resource that contains a single page application, the code and metadata for our managed package, and for support data and fields specifically for scratch orgs.
• Configured orgs can be spun up in minutes, meaning if you're working on feature X and need to start on Y, you simply create the new branch (as above) and then run ./scratch.sh to create a clean environment for Y. No more cross contamination, and no cruft in the org from elsewhere, nothing accidentally sent down the line to our packaging org.
• Easy scratch orgs for branches means better code reviews. We've always used pull requests when merging in feature branches (even when it's me issuing one to myself), and now when others submit a PR I can actually spin up an org and verify the change a whole lot more easily. Prior to DX I'd often depend largely on my judgement by reading through the code. For small changes this was fine, but for large refactors and the like, it simply far from ideal.

So What About IDEs?

Well I know all the big ones support DX, and for VisualStudio Code there's a plugin provided by Salesforce, but right now I'm not using anything. My curmudgeonly insistance on using Ubuntu via WSL means I've not had much luck using Windows IDEs with the WSL CLI. For the last few months I've been simply using Sublime and the Terminal, and so far I'm perfectly happy with that setup. That said, I do hope to cover some IDEs again in the near future, so watch this space!