Salesforce strong point was always its flexibility. You can handle any business scenarios in your Org by using both code and point-and-click tools.
That flexibility, while great, also comes with the side effect of adding complexity.
Most Org are now so complex that it's a challenge to maintain them, let alone keeping up with the always evolving business requirements.
I've been a software developer for almost 10 years now, in both small and big projects. The software development community has developed over time a lot of best practices to help us manage those large-scale projects. Before SFDX, it was hard or even impossible to use those strategies in Salesforce.
Here's how SFDX is trying to encourage those best practices.
1. Source Control
Before SFDX, Salesforce source management was Org based instead of source based. SFDX intends to change that.
What does that mean?
In Salesforce, the source of truth always used to be your production Org. Tracking changes into a Source Control tool required a lot of discipline, especially for the changes made directly in the org. like permissions, object definitions, process builder, etc.
How does SFDX changes that?
SFDX moves the source of truth from your Production Org to a version control system (like Git) by introducing a new type of Orgs: Scratch Org.
SFDX automatically track the changes you make in a Scratch Org allowing you to pull them locally, making it easy to include them into the Source Control.
To learn more about version control benefits, I strongly recommend this article.
2. Conflict Management
The current workflow of working in a Sandbox environment creates some problems, especially when working in a team.
How does the current development model can create conflicts?
Creating a Sandbox can take anywhere from 30 minutes to 24 hours. Because of that delay, we can't create a Sandbox for every user story or refresh everyone's Sandbox frequently enough to keep up with the changes. Since multiple people are working in the same Sandbox, it's easy to overwrite another developer change.
If those conflicts are detected in the same Sandbox, it's easy to manage. The real challenges are when two or more teams are working in different Sandbox and you must merge all the changes into a single Sandbox. There is no other way than to manually update one Sandbox and deploy it from there.
How does SFDX changes that?
Scratch Org and Source Control really help with those problem. Since creating a Scratch Org takes only a few seconds, it's easy to create a Scratch Org for everyone. That means you eliminate the risk of overwriting.
With the change tracking feature, the conflict management is also way easier because you can use your Source Control tools to handle them and deploy the merged version, as a package, into your integration Sandbox.
3. Org entanglement
Understanding the relationship between fields and where each one of your custom field is used is hard.
How do you currently structure your code?
While it is best practice to try and structure your code and your field in a clear manner, it's easy to use what's already available in the Org and use the same field multiple times for different concerns. It then becomes even harder to change that field because of all the different use case.
How does SFDX changes that?
Since you always start from a "Vanilla" Salesforce with a Scratch Org and because you don't want to deploy all your customization all the time in it, you really must start thinking in terms of logical packages.
SFDX allows you to create an unlocked package, which should be designed as a small logical set of customizations, including everything from code to process builder. You can have dependencies between those packages for reusability but as with any software development project, you want to keep your dependencies to a minimum.
4. Tooling
You probably already have your favorite IDE to work in, but Salesforce chose Visual Studio Code as its new official IDE. They developed an awesome set of extensions for the editor. Coming from a .NET background, I am really used to Visual Studio and Visual Studio Code so I can't be happier about that decision.
To conclude
SFDX is not a single tool nor is it a language. It's really a set of new tools and features that can bring Salesforce development closer to the industry standards and guides us toward best practices.
I hope you enjoyed this article, in the next of this series, I'll show you some concrete code example on how to get started with SFDX.
Meanwhile, I really want to know if you guys are using SFDX, how you are using it, but also your opinion on this big change in mentality for Salesforce, so leave a comment!
More information:
Comments