We have been releasing a number of Salesforce articles over the past few weeks, outlining important details about Salesforce devops adoption. The focus of this week's spotlight is Salesforce DX.
Let's go back to the 2016 Dreamforce conference to see where it all began.
Salesforce created a developer experience (DX) that was simple, open, integrated, and collaborative with the goal of enabling developers to work together and deliver continuously. In 2018, they realized their aim for a fresh and contemporary approach to developing on Salesforce.
Until the Salesforce DX launch, the deployment of Salesforce involved making general configurations of a Salesforce organization and creating Apex and Visualforce code. They do this using either the Force.com Integrated Development Environment (IDE) or the online IDE provided by the Developer Console on Salesforce.
To sum up, Salesforce DX is a more agile version of Salesforce. It is a platform created for developers to develop, test and collaborate in an effective way. This primarily involved code modularization and flexible packaging options.
Using the DX tools, automated testing, continuous integration and efficient release cycle is achieved. Developers can leverage a new Salesforce CLI to easily access APIs to use bundles. Moreover, Salesforce DX acts as an alternative to change set development, where users use change sets from an org that is used as source. A version control system can be employed as the source, shifting the development focus from org development to package development. Adopting version control allows you to track and audit the changes
Let us dive deeper to know more!
Before Salesforce DX, the deployment teams would use ANT based force.com migration tool to implement devops in Salesforce. After the introduction of DX, the Ant-based Force.com approach was replaced by the Salesforce command-line interface (CLI).
The advantage? Well, it has all of ANT’s capabilities plus commands for pushing and retrieving metadata to and from orgs, converting metadata to SFDX format, and controlling additional DX features. If you’re a developer, the Salesforce CLI will put the power of DX at your fingertips. The CLI is packed with Open APIs and interactive interfaces to develop better.
The evolution of Salesforce DX involves features with distinct advantages.
For starters, a CLI (Command Line Interface) is a text based interface, rather than a graphical based one. A text based interface is where you use the terminal in your computer to manually enter the commands you want to run, rather than clicking buttons and text. Salesforce CLI is based on an open source framework for building a command line interface in Node.js. The interactive commands can be run on a local machine or a continuous integration (CI) system,
CLI has an interactive interface and access to Open APIs that simplifies development and build automation. With CLI, orgs can be created and managed, create and manage packages. The source code can be synchronized from one org to another.Support to install custom plug-in is made available. Bringing together a cross-cloud set of commands would streamline the deployments in Salesforce.
A new type of Salesforce environment introduced by Salesforce DX was Scratch orgs. This is similar to any other salesforce environment like Sandbox, production, etc and has properties of its own.
As the name suggests “scratch” means a short-lived, disposable org with a maximum span of 30 days. This easy and convenient org consists of Salesforce code or metadata that can be easily created or destroyed, helping to speed up the standard development workflow.
Unlike the sandbox which gives a replica of the production environment, the environment cannot hold the entire production metadata. You can quickly create a scratch org to develop or test elements that you particularly need. Org customization allows users to emulate specific editions of Salesforce.
The environment is source-driven and especially created to develop and perform unit testing.
This leaves us with another question, “What is source-driven deployment?”
Salesforce DX shifts the source of truth from the org to a version control system (VCS).
If you need to push the envelope, Salesforce has always been a coding platform with development environments, code editors, unit tests, detailed logging, and deployment tools. The change set to source based was considered the evolution of collaboration brought by Salesforce DX. Using change sets to organize and test changes across projects may provide challenges as your company grows. The creation of the package quickly addresses these problems. Your source is broken up into packages based on a collection of features or customizations you plan to publish together. This way of structuring your source using packages is demonstrated by the Salesforce DX project.
For those who are new to AppExchange, packaging is a means to distribute a developed app to customers. The salesforce components will be in a package and further be hosted in App exchange for the developer to access into a new environment and transfer it.
Additionally, 2GP supports unlocked Packages that can be created in your Dev Hub, for enterprises to move towards package/source driven development. Any Scratch Org, Salesforce Sandbox, or Developer Edition Org can then be configured to install these Unlocked Packages and Package Versions.
The particular second generation packaging evolved from the 1st gen to improve the problems faced by the former. Understanding the difference between generations explains the scope of the second gen packaging.
Considering that 2GP uses a source-driven development methodology, its version control system. This represents a huge triumph over 1GP, whose deployment of metadata by the packaging organization functioned as their source of truth. Additionally, implementing 2GP makes it easier for them to precisely track their growth over time.
The org used for the 2nd gen is Dev Hub Org, and let's talk more about that!
A Dev Hub is a Salesforce org that has special capabilities and all paid Salesforce orgs and free Developer Edition Orgs can function as Dev Hubs
Enable Dev Hub features in your Salesforce org to create and manage scratch orgs and second-generation packages. It’s not necessary to enable Dev Hub if you plan to use Salesforce CLI with only sandboxes unless you plan to create second-generation (2GP) packages. The 2GP packages use a scratch org during the package generation process.
Over the time Salesforce has built custom tools and started using new practices for a better deployment process.
A definition for Optimized deployment would be to minimize run time, increase testing, and less time for debugging. For instance, test automation must be implemented to deal with up to thousands of tests on a daily basis and localize errors to identify where they are coming from.
DevOps also integrates working code on a constant basis across multiple teams to check that the code received from the various teams all integrates together without causing error conditions. All of your code enters this point and begins the build process after leaving version control.
Salesforce DX is a series of tools available in Salesforce. Apart from the primary tools like 2nd generation packaging, CLI, and scratch orgs, there are a few more tools that help for better deployment.
DX has many features to aid deployment, yet it is not a fully functional DevOps tool but rather an acceleration tool for the DevOps process. Operations can be performed such as,
If you have a larger team with multiple developers working across multiple sandboxes, or possibly using complex products such as Salesforce CPQ, then Salesforce DevOps tools might just become essential.
Overall you can expect your deployment team for more reliable deployments. It can mean increased release cadence from automation (CI/CD), which also leads to a tighter feedback loop. Having fewer bugs/errors shipped to production thanks to testing.
Better collaboration between devs & admins, partly because of the audit trail showing who changed what, when, why (version control) and a better security due to monitoring and backup.
Adopting a few practices of app creation can influence continuous delivery. Managing source code is essential, but it is not the only component of a business solution. Other components such as user interface, access control rights and static components such as icons and images, take part in the creation process must be recorded into the version control system (VCS) to keep track of any modification.
In low code platforms like Salesforce, working in a shared environment becomes a challenge. As multiple database administrations can come across each other’s changes when working in a shared environment. This helps you to make sure that developers are making changes in an isolated environment.
The capabilities of DX are embedded into Opsera, so you no longer need to integrate specifically with DX tools or functionalities to add Salesforce DX to your DevOps workflows.This means that your Opsera Salesforce pipelines/tasks will be enhanced with DX features without any additional integration or code.
For instance, Opsera integrates source control providers like GitHub, BitBucket, and GitLab with Salesforce orgs, making it easy for teams to collaborate through the source control system in a clicks-not-codes manner, without having to learn difficult CLI tooling.
Opsera is packed with key DX features inbuilt. If you are looking to incorporate DX features into your DevOps process, then Opsera is a great place to start.
Intrigued about what else Opsera offers? Visit us here or Contact us at https://www.opsera.io/contact
