Salesforce Developer Experience (SFDX or Salesforce DX) has forever changed the way application development, and release management happens on the Salesforce platform. Statistics show that companies have been improving the release quality by 15%, saving development costs by 20%, and achieving 40% faster time to market by frequent and repeatable deployments.
Can you achieve the same? Not sure? Read ahead to discover the challenges in legacy Salesforce development and get a more in-depth understanding of SFDX and scenarios in which SFDX thrives.
Is your team still living with the challenges of developing on Salesforce platform?
It’s proven beyond doubt that Salesforce helps organizations grow faster and drive superior customer experience. However, as the organizations grow, the demand for new application development, customization, and new workflows grow with it. Any Salesforce developer can tell you how challenging the platform can get when it comes to continuous development, integration, testing, and releasing new features.
One of the most complicated things that your Salesforce development team can associate with is scaffolding the entire Salesforce org and tracking the dependencies for all the developers, testers, architects, and production team.
For example, If the deployed application had five dependencies, it becomes tough for the developer to find where the dependencies were and identify the real issue that needs to be fixed.
Let’s take a deeper look at the technical challenges that any Salesforce team had to go through during the application life cycle management process.
Figure: Typical technical challenges teams faced in application life cycle management process
Traditional approaches for deploying metadata to production orgs and their challenges
Traditionally, and to great extent even today, organizations used three approaches for deploying meta-data to the production orgs:
com Migration tool – This is an ANT based deployment mechanism where one builds the application, creates the package, and uses the ANT utility to deploy the code to any version controlling system or to any Salesforce org. This model has its issues in terms of code merging and dependency tracking.
Changesets –This is an out-of-the-box feature of Salesforce. However, one needs to maintain a large excel to track all the changes that were made. Many times, changesets do not pick up the configurations. Also, the time it takes to deploy the code from one environment to another is enormous.
Unmanaged Packages – Once an application is built and the package is created, the developer deploys it on the Salesforce org. Since all the visibility is on the package, if one misses any code/class/configuration, finding the problem is going to be tough.
Here is a consolidated list of challenges that the Salesforce teams face when it comes to CI/CD, deployment, and the overall impact on the business:
Figure: Challenges in CI/CD, deployment, and overall business impact
One of the core challenges here is the absence of an immutable artifact that would help the developer to manage code changes, code merges, and find conflicts. The problem becomes insurmountable, especially during large and complex projects where changes happen daily.
Changing the game with Salesforce DX — No more ‘happy soup’ development
Salesforce Developer Experience (DX) provides an integrated, end-to-end lifecycle designed for high-performance agile development. Salesforce DX is a promising upgrade that addresses most of the challenges that traditional approaches weren’t able to solve. The platform moves away from the ‘happy soup’ mode by allowing developer, tester, and production manager to collaborate and work on different sandboxes.
One major factor in Salesforce DX is that it is aligned with DevOps and gives unprecedented flexibility to build and manage the applications on Salesforce.
Why DevOps for Salesforce application development?
Needless to say, DevOps is the best model for frequent cycles of development, testing, and release management. Here are the top reasons to consider DevOps-based release methodology for Salesforce application development.
Figure: Top reasons to consider DevOps for Salesforce application development
Core components of a Salesforce DX
While Salesforce DX comes with a rich set of features, here are the core components that will ensure that your Salesforce development team is more productive, rapid reduction in the manual errors and a high-quality release.
Salesforce DX is an open platform and allows you to use any collaboration technology across the team, code, org configuration, and metadata. Source-driven development is the core that simplifies CI/CD, allows dependency management and event package development.
Scratch Org, perhaps the most popular feature of Salesforce DX, is a disposable deployment of Salesforce code and metadata. Developers can now replicate different Salesforce editions and share the configuration file with other team members, so all have the same basic org. Scratch org significantly brings down the happy soup syndrome and ensures that every dependency is tracked.
Unlocked packages organize the metadata into a package and then deploys it to different orgs. In fact, the Second-generation packaging (2GP) allows you to create packages in a source-driven development environment. The unlocked packages are upgradable, the metadata elements are not locked so that the system admins can change them, and it allows you to build your application in a modular way.
Benefits of Salesforce DX
Salesforce DX is designed to reduce the complexity of development/testing/release management of applications on the Salesforce platform. This translates into high utilization of the platform, reduction on the development team bandwidth pressures, improvement in the release quality, significant savings on the development costs, and faster time to market by frequent and repeatable deployments. And, here is what helps you get all the benefits:
Metadata organization is simpler – Organize the pieces of metadata that make up your org into distinct modules and plan to store those modules in source control
Small and flexible packages – Start by trying to build some small modules that could become packages in order to work with source control and metadata separation techniques.
Versioning into the development life cycle – You can now incorporate package versioning and package installation into the development life cycle
Packaging into the development life cycle – Incorporating packaging into the development life cycle in an intentional and staged manner means more of the team supporting development can get a sense of how packaging will affect their work
More feedback and collaboration – Team members can provide feedback about changes in package structure to the group working on the first packages for the org, and unwanted side effects can be identified early, without affecting users in production
High-performance agile development – Salesforce DX provides you with an integrated, end-to-end life cycle designed for high-performance agile development. It has improved the development process and helps managing complex org with multiple teams.
Easily create and destroy packages – SFDX introduces a new type of Salesforce environment in Scratch orgs. These are orgs consisting of Salesforce code or Metadata that can be easily created or destroyed. It provides you DX Packaging, a container for transporting and organizing metadata in your org.
Have you moved to SFDX yet? Not sure how to do it or thinking if you are ready for SFDX or not? Talk to our experts, and we will help you demystify SFDX and ensure that your application development is more efficient and of high quality. Write to us at firstname.lastname@example.org
About the Author
Principal Architect and a Solution Lead, serving as a practice leader towards building and selling digital assets using Salesforce and AI. Expert in creating comprehensive digital strategies for enterprises undertaking digital front office and applications modernization.