When Salesforce started in 1999, they knew they were unique for their Software delivery model, SaaS (Software as a Service). It came into limelight very quickly with SaaS as its USP. SaaS model significantly reduces time, costs, and efforts required for upfront implementations and constant upgrades.
Why Salesforce DX emerged?
As time passed by, Salesforce recognized the need for a traditional Software Development Life Cycle (SDLC) platform which could help all features of a development process come together.
When a Salesforce development process involves several developers, they need to collaborate with one another. They need to shift the source of truth from Salesforce org to Version Control Systems to track the changes made by multiple developers. It facilitates source-driven development, DevOps culture, Continuous integration, and devising industry standard tools. To implement such best practices and accommodate them together at one place Salesforce needed to come up with a standard tool that:
- Integrates with source control systems
- Helps multiple people collaborate using source control
- Decomposes Salesforce metadata
- Drives Continuous Integration
Hence, Salesforce has brought in a one-stop shop solution, the Salesforce DX.
Decoding Salesforce DX
In a broad sense, Salesforce DX CLI (Command Line Interface) provides access for funneling your metadata right from source code to the delivery of an application. For this, they made sure that they support all types of authentications just like in a standard SDLC platform, right from running your test classes, changing your existing metadata into DX metadata, and pushing source control to scratch orgs.
The purpose of scratch orgs is to create an environment by Salesforce where you can easily deploy and push your code into a headless org which is not a replica of your own Production org. At this point, you specify which edition and which feature licensing you would want to take. In fact, you can enable developer edition with wave feature set and have org created with that. Salesforce is moving away from code-driven development for the entire org to app-based packaging.
The scratch orgs act like quick-to- create and quick-to-disintegrate orgs where you can check if the app they are building is working in a feature set. It basically helps you connect and drive continuous integration as a practice with the help of a few external tools. Essentially, Salesforce is still trying to stabilize Salesforce DX while integrating with the existing enterprise standard development. An end goal would be to evolve the platform into a system where it is on par with traditional software development practices while bridging the existing gaps.
An ideal work flow for a developer would be to seamlessly integrate these three silos – Salesforce DX, ALM, Feature Branches. AutoRABIT Continuous Delivery SaaS Suite complements and creates the much-needed logical chain of links between all three; making them the Fab Four.
AutoRABIT is knee deep into Salesforce DX. We are a Summit Sponsor at TrailheaDX’17. In the Summit, Niranjan Gattupalli, Head-Customer Success Services will give insights into Modern Application Development (MAD) with Salesforce DX and AutoRABIT. In the session, he will throw light on how AutoRABIT brings Salesforce DX, ALM and Feature Branches and enables Continuous Delivery of Salesforce applications. Stay tuned to learn more about the Fab Four!