Mohith is a Salesforce MVP and Salesforce Technical Architect at CodeScience. He just published a new book, “Learning Salesforce Einstein.”

I have been a developer on the Salesforce platform for 6 years now. Over the years, I have been fortunate enough to learn open-source technologies like Java, Javascript, Scala and many more. While my primary focus has been salesforce development, all throughout that journey, I have been comparing open-source developer workflow with the development workflow on the Salesforce platform.

Salesforce development on the platform consists of various challenges, such as hard-to-do continuous integration, automated testing , scaffolding entire Salesforce orgs, and keeping track of dependencies, supported IDEs for developers, and so on. The Salesforce developer community is one of the most vibrant communities and I am so thankful to the community that for all these problems we have managed to find solutions via community-contributed projects. Some of projects include open source IDEs(ie Mavesmate, Welkins Suite, ForceCode, and many more), ANT scripts to automate deployment and package.xml generation, and so on. However, last year at Dreamforce 2016, I was so excited to hear about the Salesforce DX project and now almost a year later, am glad to see the program is in BETA already and making its way to General Availability.

At the recent Midwest Dreamin’ conference, attendees explored Salesforce DX CLI and were excited about the potential of new fixes and changes.In this blog, I’m doing a deep dive on 7 Salesforce DevOps challenges that will finally end with Salesforce DX adoption. Let’s dive in!

1. Creating New Developer Orgs Painlessly with Scratch Orgs

Creating and setting up orgs is painless with Scratch org creation from CLI. The necessary commands can be explored in the official docs here.

sfdx force:org:create -f project-scratch-def.json

This will definitely allow each developer to work in their own instance and not step on each other’s code since its source control driven. One can use Github features to review, merge and test code.

2. Source Driven Development

This change is huge! Taking the source code from the version control system and auto deploying to the Salesforce instance has always been painful. It required some manual steps like creating a new Salesforce org, maintaining a script that can create a package.xml from the source code, and then maintaining ANT script to deploy code to the respective. Of course, many organizations automated this process; however, there were still certain manual steps like enabling Chatter, creating a multi-currency instance, enabling personal accounts, enabling the Service Cloud and the list goes on. Currently DX supports automatic enablement of some of these features and org preferences. All you will need to do is maintain a project-scratch-def.json file in your source control for your project.

Below is an example of a project-scratch-def.json file.

{ "orgName": "Acme", "country": "US", "edition": "Enterprise", 
  "features": "MultiCurrency;AuthorApex", 
  "orgPreferences": { "enabled": ["S1DesktopEnabled", "ChatterEnabled"], 
   "disabled": ["SelfSetPasswordInApi"] 
 }
}

This is huge time saver for sure! Check out the supported features and org preferences list in the official docs here.

The command that makes it possible to push source code to a scratch org is below:

sfdx force:source:push --targetusername [email protected]

You can also pull changes you do to the scratch org to your local using the below command

sfdx force:source:pull

In short, your source control is the source of truth, and with the config file you can at any time create a scratch org or deploy the code to any org via the command line without worrying about package.xml.

SalesforceDX Developer Workflow

3. Avoid Regression Bugs With Continuous Integration

Continuous Integration (CI) requires developers to integrate code into a shared storage several times a day, with an automated build verifying check-in. This allows for people to detect bugs earlier in the process.

Doing this on the platform has been challenging, primarily because you need skilled engineers familiar with the Force.com migration tool and APIs to build and maintain this. With ever-changing metadata in every release, this has been challenging.

Salesforce DX is CLI based, so it won’t be too difficult to set this with Jenkins, Travis, Circle or whatever your development environment is. There is already a “get started” Trailhead module to assist you with this. Having a Continuous Integration process for development will increase your developers’ efficiency and allow you to avoid regressions in your agile development.

4. Automated Test Runs For Apex Unit Tests and Lightning Components

Automating unit tests can improve quality and ensure smoother application packaging or deployment. You can configure your CI to automatically run all your Apex unit tests and tests for Lightning components.

For Apex tests, use this command:

sfdx force:apex:test:run

For Lightning components, the testing framework is in pilot and you can explore more here (Safe Harbor, of course). There are plans to make this Generally Available from Salesforce based on Trailhead Trails. It uses Jasmine Javascript Testing framework.

The command line instruction is straightforward:

sfdx force:lightning:test:run -a jasmineTests.app # run the test suite

5. Automated Data Load Between Orgs For Testing

This has been a pain point, requiring significant manual work with dataloader and other tools. Getting dataset for testing has been a challenge for developer orgs in particular.

DX makes it a step easier by writing a query and using the export command to get a JSON file. Then, you can import the JSON file back to another scratch org painlessly. You might be thinking, “What about IDs and relationships? Do we need to do excel VLOOKUP any more?” As long as there are relationships between objects and you have compiled a query, it’s straightforward. One thing still to explore is the size limit of data in the JSON file that can be exported and imported .

sfdx force:data:tree:export --query \ "SELECT Id, Name, \ (SELECT Name, AccountID\ FROM Contacts) \ FROM Account" \ --prefix export-demo --outputdir sfdx-out --plan

The above will export accounts and associated contacts, then you import the CLI again using the below command:

sfdx force:data:tree:import --targetusername <[email protected]> \ --plan sfdx-out/export-demo-plan.json

6. Assigning Permission Sets to Users

One more manual task with the current setup, that when we spin a new org and push all metadata we often forget, is to assign the permission set. Below is how that command looks:

sfdx force:user:permset:assign -n <permset_name> -u <org username/alias>

7. Multiple Orgs With Same Namespace

A common question when we began managed-package application development was, “Should we hardcode namespaces in code?” We avoided that because we could have only one org with the same namespace, and that’s used for packaging the code. Instead, we made every effort to build namespace independent-code, which provided two major advantages:

  1. Deploying code to a non namespaced org (Note that during packaging, Salesforce takes care of namespacing for most of the components; for the rest, we handled it by appending namespace dynamically).
  2. The ability to change namespaces later.

With Salesforce DX, one could have multiple scratch orgs with same namespace. This means that if we are 100% confident and namespace is decided upfront we can hardcode it. That makes building Lightning components easier without having to worry about workarounds. However I will still caution and recommend to keep the code namespace independent.

DX requires enabling Developer Hub in your business org. You will need to register for the namespace using the process discussed here.

Then we can create a scratch org with a namespace by using command shown below:

sfdx force:org:create -f project-scratch-def.json

Can we immediately Adopt Salesforce DX if it has so many advantages?

For ISV apps, it looks like a straight forward process. However, it might get tricky if you have extension packages and too many metadata components. There is a simple command to convert an unmanaged package and integrate it with a DX compatible folder structure. An example where dir is the folder where you have unzipped your unmanaged package follows:

sfdx force:mdapi:convert -r ./dir

For Salesforce CRM applications, it’s not a straight-forward move, and requires significant investment. It will require breaking your application into a series of unmanaged packages and modules. The biggest lesson is to always approach your Salesforce projects in your enterprise organizations as modules. It’s easier to manage and maintain. However, if you are building something for a new business unit and there are not many dependencies on existing code, you can adopt DX for this build and keep all code and metadata source-driven.

What about IDE options once we scaffold the application and are ready for coding?

There are couple of options here from Salesforce.

  • Force.com IDE2, which is Eclipse-based. (I am not a big fan of Eclipse.)
  • VisualStudio Extension Pack — I love lightweight editors! Visual Studio Code is awesome and the plugin covers the functionality of SalesforceDX, plus at the same time provides syntax highlighting and code completion.

Conclusion

Salesforce DX is a great step forward and will ease development difficulties on the platform. It encourages collaborative development (and rightly so) because you accomplish more as a team instead of going it alone.


Since this post discusses beta features, Salesforce safe harbor applies.

Important: Salesforce DX is available as a beta. Salesforce DX isn’t broadly available unless or until Salesforce announces its general availability in documentation, press releases, or public statements. All commands, parameters, and other features are subject to change or depreciate at any time, with or without notice. Don’t implement functionality developed with these commands or tools.


Want to keep your app up to speed with the latest Salesforce changes? Put our expertise to work for you. Get started at www.codescience.com/services.