Published on October 5th, 2019 | by Bibhuranjan

Major DevOps Challenges that Salesforce DX can Handle Effectively

Salesforce is a continuously evolving platform, and the developers on it face many challenges from time to time including deficiencies in terms of automation of testing, continuous integration, scaffolding the org, keeping track of all dependencies, IDEs developers can use, etc. Thankfully, the developer community of Salesforce is quite active and very vibrant, where you can find support for all such issues through the community projects.

Many of these projects also include some open source integrated development environments like Welkins Suite, MavesMate, Force Code, to name a few. You can also find some community-contributed projects like ANT scripts for automation of package, deployment, and .xml generation, etc. In fact, the provider itself takes now an initiative to tackle these challenges of continuous integration and automated testing with the introduction of Salesforce DX.

Salesforce DX helps create developer orgs in a much easier and painless way with the help of Scratch orgs. Creation of scratch orgs and setting it up is a much painless task on Salesforce DX. You can explore the CLI commands which are needed by referring to the official docs. Salesforce DX allows each of the developers to independently work on their own instances without stepping into the codes of others as the approach is source-driven.

The concept of source-driven development

For a long time now, it was a bit painful to take source code out from version control and then deploy it to the Salesforce instance. This required a lot of manual steps as like creation of Salesforce orgs and maintaining the scripts to create package.xml out of the source code and to retain the script and for the deployment of code.

Many of the development teams which have automated this process had to follow many manual steps as like creation of multi-currency instances, enabling the chatter or person accounts or establishing service cloud, etc. Now, the latest release of Salesforce DX supports default enablement of many such features and developers can custom set each org preferences. For this, you need to maintain one file as “project-scratch-def.json” at the source control. This can save a lot of time and effort for the developers.

In short, the source control also acts as the source of truth, and the developers can create a scratch org at anytime or directly deploy the code to any of the orgs through CLI without worrying for the package.xml.

The development workflow in Salesforce DX

CI or Continuous Integration is a modern-day development need which wants the developers to integrate their codes into a common-share repository which is updated many times a day. All the check-ins to do it will get verified by automated builds which allow the development team members to detect problems if any at the first point. Doing this on the Salesforce platform had been challenging as there was a need for experienced engineers who are well versed in force.com APIs and migration tools to build this and maintain it with constantly changing metadata.

On the other hand, Salesforce DX is now a CLI-centric platform, which makes it easier for the developers to set it with Travis, Jenkins, or Circle or any other random environment they prefer. Salesforce providers like Flosum started trailhead modules also to support the developers. Featuring a continuous integration for development will help enhance the developer efficiency and also avoid any regressions in an agile development environment.

Automated testing for Apex unit tests

Automation of the unit tests will surely help to enhance quality and also make the application packaging much smoother. The deployment will also be much easier with this approach. Developers also may custom configure their CI to run the apex unit tests automatically and then test these for the lighting components. The command for apex tests is:

Another major pain point in Salesforce as the automation of data load between the orgs. A lot of manual work was needed with the data loader and other allied tools. With this, it was difficult to get enough datasets for testing. Now, Salesforce DX makes this step much easier by using the export command and also writing the query to get the JSON file which enables import to a different scratch org easier.

Assigning user permissions

Another manual task which had been troublesome for long, now taken care of well by Salesforce DX is assigning permissions to users. On DX, you can spin a new Scratch org to push all the metadata which we often tend to forget while done manually. The command used for this may look like below.

Handling multiple orgs at same namespace

Another major question developers may raise while starting with managed packages is whether there is a need to hardcode the namespaces while coding? For those who have one org, this had been avoided within the same namespace, and it is used for packaging the code. The major advantages of Salesforce DX are:

You can deploy the code to org, which is non-namespaced. Salesforce takes care of namespacing during packaging for the majority of the components, and for the rest, you can append namespace dynamically.
It is possible to change namespaces at a later date.

You can have different scratch orgs with the same namespace on Salesforce DX. This further makes it easier to build lightning components without any need for workarounds. However, the expert recommendation is to keep code namespace independently. DX also requires Developer Hub to be enabled in the business org you create.

Do we adopt Salesforce DX instantly with these many benefits?

For the ISV applications, usage of Salesforce DX seems to be a much straight forward and quicker process. However, sometimes it may get trickier if you have some extension packages or a lot of components. You may use this simple command in such cases to convert the unmanaged packages and then integrate it with a compatible folder structure.

For the SI applications, it requires further breaking down your application to a larger series of modules and packages, unmanaged. So, the biggest things to do is to approach your newest Salesforce projects in modules. Doing this, it becomes easier to manage and maintain these. However, if the need is to build something from scratch for new business and there are no other dependencies on any of the existing code, then you can instantly grab Salesforce DX to build with a source-driven approach.

Tags: CRM, development, DevOps, sales, Salesforce

About the Author

Bibhuranjan Editorial Officer, technofaq.org I'm an avid tech enthusiast at heart. I like to mug up on new and exciting developments on science and tech and have a deep love for PC gaming. Other hobbies include writing blog posts, music and DIY projects.