Date published • 9th August 2018
I have to admit I've been looking forward to this one, after going through the tools and usual lifecycles (and ranting about my views as well).
This post is going to be dedicated to describe my experience, views and decision making process about Salesforce DX, including where and when to use it (or not). Keep in mind that this is all accurate only as of the date of the post creation (August 2018), and as far as I've used it and researched. I'll try to update this one or follow up on different posts in the future. As usual, please comment if there's something you believe I should add or update!
If you want more of a detail about what DX is and some quick start instructions, there's a pretty good blog series on all things DX here: https://developer.salesforce.com/blogs/2018/02/getting-started-salesforce-dx-part-1-5.html. There's also the dev guides, of course.
Let's get to it.
As I mentioned lightly earlier in the series. After a long time of not treating developers (and configurators and testers and architects...) as well as they could and should, Salesforce is starting on the path to make the development experience (i.e. DX) a lot better for all.
After having to live with change sets, manual deployments through IDEs (or just by hand!), ant migration tool antics, it's actually refreshing to see that better ways to implement new features and/or changes in the core platform are coming.
Even though it has been around for over a year, DX hasn't been widely adopted for many reasons, which I'll try to explain in this post, as clearly as I can.
Things I like about it
There are quite a few things I really like about DX. Don't take my word for them unless you've read the whole post and the things I don't like, though, to get the full picture.
Things I don't like about it (at least yet)
Ok, if you see the list above on it's own, you'll probably think I'm a DX evangelist and super optimistic (or perhaps you chose other words) about it. But even though I am reasonably optimistic about the future of DX, I'm not sure it's still a full product, unfortunately.
List of things I don't like (at least yet):
When to use it and when not to
In my view, if you and your implementation can fully relate to the following points, I think you should give DX a go:
When not to use it (sadly):
About Unlocked packages and all DCPs (they're still BETA)
I wanted to add a specific section on these, as I find them really useful and a great idea. Of course, always with the caveat of the limitations and things I like and don't like, mentioned above.
For some context, the following things are what I believe will make them super useful:
I find it super annoying that, while unlocked packages are not generally available (and complete enough), we have to use DX just for the "dev train" and switch to metadata API deployments for the "release train"! I know there are CLI commands to convert and deploy/retrieve, but still. Having said that, when this is possible, it's still better than before DX, in my opinion.
Considerations, things to be aware of and things I don't have answers for just yet:
Some thoughts to wrap the post up:
Give DX a shot and please let me know how you got along with it, I'd love to hear your stories and experiences with it
Next in the series: wrap up, future predictions for Salesforce and DevOps and my personal wish list
Ivan, Head of Architecture
If you would like to know more about what we do, we’re happy to answer any questions you may have for us.
Share this article: