Salesforce DX

5 DevOps Challenges Resolved in New Salesforce DX

Salesforce development comes with various challenges for the fellow developers like the hardships in continuous integration, testing automation, scaffolding the Salesforce orgs in its entirety, keeping track of the dependencies and also the supported IDEs, etc. The developer community of Salesforce is one of the most happening places, which we should thank for the fix of all these problems by the experts.

Some of the community-contributed projects also include the open-source IDEs (like Welkins Suite, ForceCode, Mavesmate, and so on). However, the latest Salesforce DX comes with many instant solutions for the above-mentioned problems and is fully equipped to meet up with the DevOps challenges. Let’s have an overview of these.

1. Creation of Developer Orgs with Scratch Orgs

Creation of the orgs and setting these up is now a much painless now with the features of Scratch org creation directly from the command line interface. The commands for Salesforce DX Scratch org can be found at eh official docs. This will let the developers work in their unique instance without stepping into the codes of each other as the development is primarily source-driven. You can use the Git hub features in order to develop, review, test, and merge the code.

2. Source-drive approach

Taking source code out of the version control system and then deploying it to the corresponding instance had been a painful affair. it involved many manual steps such as the creation of new org, maintaining the script to create package.xml at the source code, and also maintaining the ANT script for code deployment. Now, Salesforce DX can automatically enable many of these features and preferences. All that developers have to do is to maintain a file titled “project-scratch-def.json” at the source control. Please find the below example of such a file:

This can surely save a lot of time and effort.

3. Avoid any regression bugs

CI or Continuous Integration will let developers integrate the code further into a shared storage space, which is run multiple times a day. There is also an automated build check-in to verify. This lets the developers detect any bugs well ahead in the process. Doing it on the Salesforce platform had previously been a challenging affair as it required the engineers to be familiar with the migration tools of Force.com and different APIs to build it and maintain it.

Salesforce DX is, by default, CLI-based. With this capability, it will not be difficult to set it with any Jenkins, Circle, Travis, or whichever development environment you use. This is an instant start module to assist developers. With a Continuous Integration approach to development, it will increase the efficiency and productivity of your developer team and also let them avoid any regressions in the agile development model.

4. Automated test runs

Automating the unit and integration testing will further improve the quality of the apps and also ensure smoother packaging and deployment. The CI can be easily configured, and you can automatically run the tests for the Lightning components. The command for Apex tests is

5. Automated data load for testing between orgs

This was another pain point in the old version, requiring a significant manual effort with the data loader and such tools. However, Salesforce DX made is easier with a query and also using export command to call a JSON file. Next, you can simply import this JSON to another scratch org too effortlessly.

As far as there is a relationship between the objects and there is a compiled query, then Salesforce DX testing is straightforward.

Read Also

5 Best AMD Graphics Card for Pro Gamers

Zubair Hussain Khan – a foodie by choice and tech enthusiast by profession. He loves to get his hands into modern technology trends and share the knowledge with everyone. He is the co-founder of criticinfo.com. Aside of the work life, Zubair loves to travel new places and explore nature, food is still his first love though!

Leave a Reply

Your email address will not be published. Required fields are marked *