Release Management through SFDX in Salesforce

There are numerous ways to implement the CI/CD (Continuous Integration / Continuous Delivery) process in Salesforce.

Let me explain with an example. Let's say we have 4 Orgs in our System

Dev Sandbox (Where the actual cooking happens by the developers)
Partial QA Sandbox (Where the code is deployed by developers and is tried and tested by our QA Folks)
Pre-Prod Sandbox (Where the code is deployed from PartialQA, but by our DevOps folks and is again validated by the QA Folks)
Production (The ultimate destination)

Before I get into the deployment through SFDX, I'll go through the development and deployment through the normal process.

As explained in the diagram above, if we'd be going through the traditional approach the following points are worth noting:

All the developers would be doing their development in the Dev Sandbox and each developer would have instant access to the code change done by the peer developer as the Code instance is the same, while there are users created for each developer in the same instance.
The different tools available for the source control / version control could be Git / Bitbucket / Mercurial, etc.
Now, as shown in the diagram, the development would happen in the Dev Sandbox. Once the development is completed, the code would be retrieved from the sandbox and pushed to the feature branch in Git. From the feature branch, it would be merged to the Dev Branch (P.S. : The feature branch was originally created from the Dev Branch). To do that, we could either use the easy tools like Github Desktop or SourceTree. If we don't have those tools available, we could also use GIT CLI.
Now, that we have the code in our Git Branch, we would need to push it to our higher sandbox i.e. PartialQA. To do that, we'd need a deployment tool like Jenkins / Copado / AutoRabit ,etc. It could also be done with SFDX force:deploy commands.
The same steps above would be now repeated to deploy to further orgs.
Let's say, we didn't have the version control system and the integration tools with us, then the deployment between the orgs would happen through the changeset. But, this does come with a risk of code overrides, delays in deployment, non-selective deployment, misses in deployment, etc.

Now, let's see the process happen through SFDX CLI.

The first and foremost major difference between the traditional approach and SFDX CLI is the option to create Scratch orgs.

Remember how we spoke above about one Dev Sandbox with multiple users which would mean that the change done by one developer also reflects to another.

With scratch orgs, that's not the case. Each developer creates their individual development instance called scratch org and don't have any visibility to the changes done by the peer developer. This gives each developer a clean working instance. Let me elaborate a bit more about what's scratch org:

Scratch Orgs are temporary Salesforce Orgs where developers will build source code and configure an application.
Scratch Orgs are not permanent and expires in a max of 30 days.
Scratch orgs are created from the Dev hub
In order to enable DevHub in your developer edition / trial / production org / business org, you first need to enable Devhub.

With the above implementation, the source of truth isn't the code present in the Sandbox anymore, because Scratch Orgs are temporary orgs. It's the other way around. The source of truth is the version control system i.e. the code repository present in our Git / BitBucket.

During the initial setup, i.e. before a scratch org is created, the code is retrieved from the DevHub and is stored in the Version control system, which means that it is the latest copy of the code that the end user sees. From there, it is then deployed to the scratch orgs using sfdx push commands. Only the required component may need to be deployed and not all if there are no major dependencies.

While the development is being done, the code in the Visual Studio Code is constantly kept in sync with the Scratch org. Once the development is done, a package of the updated component is created and is pushed to the respective org like PartialQA or Pre-Prod for testing. So, at any given point of time, the code in our Version control system is up to date.

Hope this blog gave a clear understanding of the high level process of development and deployment in both sandbox driven and source driven process. Do let me know in the comments below if you found this post useful. Which deployment process do you use to deploy your code component?

Image Source :

Receive my updates