Salesforce

Developer Experience
 Table of Contents

1. Introduction 1

1.1 What and Why Salesforce DX? 1

1.2 Who is this Whitepaper for? 1

1.3 Devops and Salesforce 2

2. Salesforce DX - An Overview 5

2.1 Developer Hub (Dev Hub) orgs 5

2.2 The Salesforce CLI 6

2.2.1 Install the Salesforce CLI 6

2.3 Scratch Orgs 7

2.4 A new metadata format 8

2.5 Visual Studio Code Plugins 9

2.5.1 Install Visual Studio Code 9

2.5.2 Install Salesforce Extension Package 10
2.6 Second Generation Packaging (2GP) 11
2.6.1 Advantage 11
2.6.2 Limitations 12
2.7 Dependency API 13

3. Salesforce DX - Setup a Project 13

3.1 Set up your project 13

3.2 Authorize the Developer Hub org for the project 13

3.2.1 Login into Dev/Sandbox Org from CLI 13

3.3 Configure your local project 14

3.4 Create a scratch org 14

3.4.1 Create the scratch org 14

3.4.2 Open the org 15

3.4.3 Set default user 15

3.4.4 Display All Orgs 15

3.5 Push the source from your project to the scratch org 16

3.6 Develop the app 17

 Table of Contents
3.6.1 Create Source Files from the CLI 17

3.6.2 Edit Source Files 17

3.7 Pull the source to keep your project and scratch org in sync 18

3.8 Run tests 18

3.9 Export The Package.xml 19

3.10 Convert Source code to Salesforce DX 20

3.11 Track Changes Between the Project and Scratch Org 20

3.12 Sync up 20

4. DX for Salesforce DevOps 20

4.1 Best Practices 20

4.2 Version Control System (VCS) 21

5. Challenges 22

6. Conclusion 23

7. About DemandBlue 23
1 Salesforce Developer Experience

1. Introduction
Salesforce Developer Experience (DX) is a brand new way to develop and manage apps on the
Lightning Platform across the entire life cycle. It combines the best of the Lightning Platform to
enable source-driven development, team collaboration with governance, and new levels of agility for
custom app development on Salesforce.

1.1 What and Why Salesforce DX?

What
Salesforce Developer Experience (DX) is a unique set of tools that streamline the entire development
life cycle.

Why
To improve team development and collaboration, it facilitates automated testing and continuous
integration, and makes the release cycle more efficient and agile.

Salesforce DX is much more than just a new set of tools. It provides an alternative to change set
development and shifts the source of truth from the org to version control system (VCS). It shifts our
development focus from org development to package development.

1.2 Who is this Whitepaper for?

This whitepaper is for Salesforce developers and admins who want to understand more about
Salesforce DX (Developer Experience), and how it might be used to implement a DevOps process
that works for technically diverse development teams. Salesforce DX will likely impact you, potentially
changing the way you work. If you’re involved in the administration, development, maintenance, or
management of Salesforce environments, then this whitepaper is for you. It will provide you an
overview of Salesforce DX, an understanding of its motivating factors, the workflows it facilitates
and practical considerations for its adoption. If you’re an admin, architect, developer or team lead
considering trialing and adopting Salesforce DX for your team, then this whitepaper has something
for you.
2 Salesforce Developer Experience

1.3 Devops and Salesforce

Establish Source Code Control
• Establish Git Repository as “golden source” of the entire solution for both code and
configuration
• Bring transparency and governance to the code review process
• Achieve environmental consistency with dynamic, repeatable deployments to every
environment

Empower the Developers

• Provides real-time deployment validation feedback to developers with deployment errors
• Empower developers to resolve their own issues, rather than back-and-forth with an
environment manager
• Keep the release branches 100 percent deployment-ready as errors are never committed

Continuous Deployment Lifecycle

• Automated, immediate validations and deployments when the code is merged
• On-demand, triggered, and scheduled deployments to keep any number of environments
in-sync
• Add Selenium regression testing scripts and automated code review tools to DevOps
pipeline

Seven Salesforce DevOps Challenges that will be resolved with new

Salesforce DX

1 Seamlessly creating new developer orgs with Scratch orgs

It allows each developer to work with their own instance and without stepping on each others’
code, and one can use github features to review, merge and test code.

2 Source Driven Development

Ability to take source code from the version control system and auto-deploy to the salesforce
instance have been pain.
3 Salesforce Developer Experience

It needed some manual steps like creating a new salesforce org, maintaining a script that
can create a package.xml from source code and maintaining ANT script to deploy code to
the respective. Of course many organizations have automated this process, however certain
manual steps including enabling chatter, enabling Person Accounts, creating multi-currency
instance, Enabling Service Cloud and so on. Currently, Salesforce Developer Experience
supports automatic enablement of some of these features and org preferences. All you need
to do is maintain a project-scratch-def.json file in your source control for the project.

3 Avoid Regression Bugs with Continuous Integration

Continuous Integration (CI) is a practice that needs developers to integrate code into a shared
repository several times each day. Each and every check-in is verified by an automated
build, enabling teams to identify problems early.

Doing this on the platform has been quite challenging, predominantly because you need
skilled engineers familiar with force.com APIs and migration tools to build and maintain this
and with ever-changing metadata with every release this has been challenging.

4 Automated Test Runs For Lightning Components and Apex Unit Tests
Automating unit tests can certainly help quality and ensure smoother application packaging
and deployment. You can configure your Continuous Integration to automatically run your
apex unit tests and tests for lightning components

Below is the command for apex tests

sfdx force:apex:test:run

5 Automated Data load between Orgs For Testing

This has been a pain point where there was a need for a lot of manual work with dataloader
and other tools. Getting dataset for testing has been a pain point specifically for developer
orgs.

DX makes it one step easier by writing a query and using export command to get a JSON file
and then seamlessly import the JSON file back to another scratch org. You might be thinking
about IDs and relationships – if you need not do excel VLOOKUP any more.
4 Salesforce Developer Experience

For as long as there are relationships between objects and you have compiled query, it is
straight forward. One thing that has to be explored is the limit of data 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 Account and associated Contacts and then import using the CLI again
using the command below

sfdx force:data:tree:export --query

“SELECT Id, Name, (SELECT Name, AccountID FROM Contacts) FROM Account”
--prefix export-demo --outputdir sfdx-out --plan

6 Assigning Permission Sets to Users

Another manual task when we spin a new org and push all the metadata that we often forget
is to assign permission set. Below is how the command assigns permission set

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

7 Multiple Orgs With Same Namespace

One common question when we began managed package application development was if
we should hardcode namespaces in code. We avoided this because we could have only one
org with the same namespace and that is used for packaging up the code. So we made all
the efforts to build namespace independent code. It gave two major advantages:

1. Deploy code to non-namespaced org

(Note that while packaging salesforce looks after namespacing for most of the components
but for the rest we handled it by appending namespace dynamically).
5 Salesforce Developer Experience

2. Change namespaces later

With Salesforce DX, you could have multiple scratch orgs with the same namespace and
therefore what this would mean is if we are 100% confident and namespace is decided
upfront we can hardcode it in the code. This makes building lightning components easier
without having to worry about workarounds. However, we would still caution and recommend
you to keep the code namespace independent.

2. Salesforce DX - An Overview
Salesforce Developer Experience (DX) is a brand new way to manage and develop apps on the
Lightning Platform across the entire life cycle. It combines the best of the Lightning Platform to
enable source-driven development, team collaboration with governance, and new levels of agility for
custom app development on Salesforce.

• With Salesforce DX, we can use the developer tools you already know.

• The ability to apply best practices to software development. Source code and metadata
exist outside the org and provide more agility to develop Salesforce apps in a team
enviroment Instead of the org, version control system is the source of truth.

• With a powerful command-line interface (CLI) it removes the complexity of working with
your Salesforce org for development, continuous integration, and delivery.

• Flexible and configurable scratch orgs you build for development and automated
environments. This type of org makes it easier to build your apps and packages.

• We can use any IDE or text editor you want with the CLI and externalized source.

• Salesforce Extensions for VS Code to accelerate app development. These tools provide
features for working with scratch orgs, Apex, Lightning components, and Visualforce.

2.1 Developer Hub (Dev Hub) orgs

Developer Hub (Dev Hub) is the key Salesforce org that you and your team use to create and
manage our scratch orgs.
6 Salesforce Developer Experience

Enable Dev Hub in Your Org

Ref:
https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_enable_devhub.htm

(or)
Get your own 30-day Dev Hub Trial Org at:
https://developer.salesforce.com/promotions/orgs/dx-signup

2.2 The Salesforce CLI

Salesforce CLI is used to control the full application life cycle of the Salesforce apps. With it you can
easily create environments for development and testing, synchronize source code between your
orgs and VCS, and execute tests.

2.2.1 Install the Salesforce CLI

Salesforce CLI is used to control the full application life cycle of the Salesforce apps. With it you can
easily create environments for development and testing, synchronize source code between your
orgs and VCS, and execute tests.

1 Enable Dev Hub in Your Org

Ref:
https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_enable_devhub.

htm

(or)
Get your own 30-day Dev Hub Trial Org at:
https://developer.salesforce.com/promotions/orgs/dx-signup

2 Add Salesforce DX Users

Ref:
https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_add_users.htm

3 Install the Salesforce CLI

Make sure that we have the latest version of the Salesforce CLI installed and the system meets the necessary

requirements.

Go to:
https://developer.salesforce.com/tools/sfdxcli and get the latest version.
7 Salesforce Developer Experience

Verify Salesforce CLI Installation

• Verify Salesforce CLI installation and plug-in versions.

• Run the command below to verify the Salesforce CLI version:
sfdx --version
sfdx-cli/6.0.10-3713d7b alpha (darwin-x64) node-v8.6.0
• Run the command below to verify the Salesforce CLI plug-in version:
sfdx plugins --core
salesforcedx 41.2.0 (core)
Salesforce CLI Command Reference

For information about installing Salesforce CLI, see the Salesforce DX Setup Guide.

2.3 Scratch Orgs

Scratch org is a fully dedicated, configurable, and short-term Salesforce environment. Scratch
orgs enable developer productivity and collaboration during the development process and facilitate
automated testing and continuous integration.

We can spin up a new scratch org when we want to:

• Start a new project

• Start a new feature branch

• Test a new feature

8 Salesforce Developer Experience

• Start automated testing

• Perform development tasks directly in an org

• Start from “scratch” with a new org

Though scratch orgs are meant to be disposable, the scratch org configuration files contain
the real brawn. Through the configuration file, we can configure the scratch org with different
Salesforce editions and with just the features and settings we want. And we can share the
scratch org configuration file with other team members. That way, we all will have the same
basic org in which we can develop.

• Scratch orgs are not replace Sandboxes

• Scratch orgs aren’t meant to be replications of sandboxes or production orgs

• A Dev Hub provides us the ability to create and manage scratch orgs.

• Scratch orgs are temporary Salesforce environments where we can do the bulk of
development work in this new source-driven development paradigm.

• We can use the CLI or Salesforce Extensions for VS Code to open our scratch org in a
browser without logging in

2.4 A new metadata format

In Ant and the Force.com migration tool, the APIs used by Salesforce DX are the same whereas in
Force.com migration tool will know that the structure of metadata returned by those APIs isn’t ideal
for working from version control system. In general custom objects and profiles can cause these
issues -

• Making working with large XML files difficult

• If multiple users changing the same files make conflicts and failing to resolve these
effectively can yield corrupt XML

• It’s not uncommon for these items to contain a variety of different changes according to
different features in active development in a particular org - this means when pushing
changes, developers need to edit these XML files by hand to incorporate only the specific
changes they want to push in that deployment or commit
9 Salesforce Developer Experience

To overcome this-

• DX uses a slightly modified folder structure that breaks up some of the larger, more
complex metadata into subcomponents, providing a good workaround to these problems.

• It’s worth noting, however, that because it uses the same underlying APIs there are still
problems this mechanism doesn’t address.

• It also comes with the added benefit of loosening some of the restrictions on folder
structure, allowing you to introduce subfolders to organize your Apex classes

Metadata Coverage
https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_supported_mdapi_types.

htm

2.5 Visual Studio Code Plugins

Visual Studio Code is a powerful editor. It is highly customizable and is cross-platform. Salesforce
extensions provide unique features such as code completion, syntax highlighting, Apex live
debugging, and more for the Lightning Platform.

Salesforce has already mentioned that the Salesforce Extensions for VS Code are the future of
Salesforce development. They have dedicated their resources to make this the best and most
enjoyable desktop editor for Salesforce developers. With this focus on Visual Studio Code, Salesforce
is moving away from our support of Eclipse. While the Force.com IDE will be supported and will
receive some updates in the near future, the updates will focus mainly on compatibility (and of
course, security if needed). Salesforce will not be adding any new major features to the Force.com
IDE and we will eventually deprecate it entirely.

2.5.1 Install Visual Studio Code

In Ant and the Force.com migration tool, the APIs used by Salesforce DX are the same whereas in
Force.com migration tool will know that the structure of metadata returned by those APIs isn’t ideal
for working from version control system. In general custom objects and profiles can cause these
issues -

1 Download and install the latest version of https://code.visualstudio.com/download (Skip, if

we already have it installed.)

2 Install it
10 Salesforce Developer Experience

2.5.2 Install Salesforce Extension Package

With Salesforce Extensions for Visual Studio (VS) Code, we get a powerful integrated development
environment that’s created particularly for custom development on the Lightning Platform. These
extensions enable:

• Functionality to interact with Salesforce CLI

• Functionality to create projects for package development

• Access to Apex Language Server for syntax highlighting and code completion

• Support for Lightning component bundles

• Support for Visualforce pages and components

• Support for interactive and replay debuggers

1 Launch Visual Studio Code

2 On the left toolbar, click the Extensions icon (the last icon down)
11 Salesforce Developer Experience

3 Search for “Salesforce Extension Pack”

1. Install the extension pack

2. Click the “Reload” button to re-launch VS Code

2.6 Second Generation Packaging (2GP)

Second-generation packaging (2GP) allows customers and system integrators to create packages
in a source-driven development environment. We can create and deploy packages in your own
Salesforce org or develop and distribute packages to your customers.

2.6.1 Advantage
Use packaging to take advantage of these helpful features:
• The Salesforce CLI provides commands for the entire application life cycle so you can work
efficiently with your packages, scratch orgs, and development processes

• Options for enterprise customers to organize and deploy metadata to production orgs

• Multiple packages per namespace, so you can better organize your source and easily share
Apex code. You can use public Apex classes across packages rather than global Apex classes
12 Salesforce Developer Experience

• Feature branch development and testing

• Completely API-driven functionality

• Packages that are built directly from the source

• Ease of development and distribution of dependent packages

2.6.2 Limitations
Unable to Specify a Patch Version

Description:
The four-part package edition number includes a patch segment, known as major.minor.patch.build. However, you

cannot create a patch for a second-generation package. Package creation fails if you set a patch number in the

package descriptor. Stay tuned for patch versions in an upcoming release.

Workaround:
Always set the patch segment of the version number, to 0. For example, 1.2.0.1 is valid but 1.2.1.1 is not.

Protected Custom Metadata and Custom Settings are Visible to Developers in a Scratch
Org If Installed Packages Share a Namespace

Description:
Use caution when you store secrets in your second-generation packages using protected custom metadata or
protected custom settings. You can create multiple second-generation packages with the same namespace.

However, when you install these packages in a scratch org, these secrets are visible to any of your developers that

are working in a scratch org with a shared namespace. In the future, we might add a “package-protected” keyword

to prevent access to package secrets in these situations.

Workaround:
None

Source:
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp.htm
13 Salesforce Developer Experience

2.7 Dependency API

Salesforce DC provides the flexible and powerful Salesforce Command Line Interface (CLI) where
we can use CLI to manage package development process from the command line.

The CLI combines capabilities from across several Salesforce APIs, such as Metadata API, Tooling
API, and Data (SOAP) API. It also supports the functionality of Ant Migration Tool that allows for
scripting of metadata tasks. With the new and improved CLI, all our development tasks from all the
important APIs are available in one place. We can script everything from the creation of orgs to the
import and export of data–everything required to manage the complete development life cycle.

3. Salesforce DX - Setup a Project

Follow the basic workflow when you are starting from scratch to create and develop an app that runs
on the Lightning Platform.

3.1 Set up your project

Salesforce DX introduces a new project structure for your org’s metadata (code and configuration),
your org templates, your sample data, and all your team’s tests. Store these items in a version
control system (VCS) to bring consistency to your team’s development processes. Retrieve the
contents of your team’s repository when you’re ready to develop a new feature.

3.2 Authorize the Developer Hub org for the project

The Dev Hub org enables you to create, delete, and manage your Salesforce scratch orgs. After you
set up your project on your local machine, you authorize with the Dev Hub org before you can create
a scratch org.

3.2.1 Login into Dev/Sandbox Org from CLI

The Dev Hub org enables you to create, delete, and manage your Salesforce scratch orgs. After you
set up your project on your local machine, you authorize with the Dev Hub org before you can create
a scratch org.
Run the force:auth:web:login CLI command on a directory where code for deploy to
sfdx will be available.
sfdx force:auth:web:login –d
(or)
sfdx force:auth:web:login --setdefaultdevhubusername --setalias {ALIAS HERE}
14 Salesforce Developer Experience

NOTE
Login must be a valid login to your Dev/Sandbox Org and with Admin permissions
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth.htm

3.3 Configure your local project

The project configuration file sfdx-project.json indicates that the directory is a Salesforce DX project.
The configuration file contains project information and facilitates the authentication of scratch orgs
and the creation of second-generation packages. It also tells the CLI where to put files when syncing
between the project and scratch org.
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm

3.4 Create a scratch org

After you create the scratch org definition file, you can easily spin up a scratch org and open it
directly from the command line.

3.4.1 Create a scratch org

• Create a scratch org for development using a scratch org definition file
The scratch org definition defines the org edition, features, org preferences, and some other
options.
sfdx force:org:create -f project-scratch-def.json

• Specify scratch org definition values on the command line using key=value pairs
ssfdx force:org:create [email protected] edition=Developer \
[email protected]

• Create a scratch org with an alias

Scratch org usernames are long and unintuitive. Setting an alias every time you create a
scratch org is an amazing way to track the scratch org’s function. And it is much easier to
remember when issuing subsequent CLI commands.
sfdx force:org:create -f project-scratch-def.json -a MyScratchOrg

• Create a scratch org for user acceptance testing or to test installations of packages
In this case, you don’t want to create a scratch org with a namespace. You can use this
command to override the namespace value in the scratch org definition file.
sfdx force:org:create -f project-scratch-def.json --nonamespac
15 Salesforce Developer Experience

• Indicate that this scratch org is the default

CLI commands that are run from within the project use the default scratch org, and you
don’t have to manually enter the username parameter each time.
sfdx force:org:create -f project-scratch-def.json --setdefaultusername

• Specify the scratch org’s duration, which indicates when the scratch org expires (in days).
The default is 7 days. Valid values are from 1-30.
sfdx force:org:create -f config/project-scratch-def.json --durationdays 30
sfdx force:org:create -f config/project-scratch-def.json -d 3

• Standard output displays two important pieces of information: the org ID and the username.

• Successfully created scratch org: 00D3D0000000PE5UAM,

• username: [email protected]

3.4.2 Open the org

If you want to open the scratch org
sfdx force:org:open -u <username/alias>
If you want to open the scratch org in Lightning Experience or open a Visualforce page, use the
--path parameter.
sfdx force:org:open --path lightning

3.4.3 Set default user

Copy the username and enter the following command to set the default username:
sfdx force:config:set defaultusername={SET THIS TO NEW SCRATCH ORG’S USERNAME
FROM THE ABOVE COMMAND}

3.4.4 Display All Orgs

Run the following command to confirm the default Dev Hub [marked with (D)] and Active Scratch Org
[marked with (U)]:
sfdx force:org:list --all
16 Salesforce Developer Experience

3.5 Push the source from your project to the scratch org

1 To push changed source to your default scratch org:

sfdx force:source:pushrequirements.

2 To push changed source to a scratch org that’s not the default, you can indicate it by
its username or alias :
sfdx force:source:push --targetusername [email protected]
sfdx force:source:push -u [email protected]
sfdx force:source:push -u MyGroovyScratchOrg

3 Selecting Files to Ignore During Push

It’s likely that you have some files that you don’t want to sync between the project and
scratch org. You can have the push command ignore the files you indicate in
.forceignore.

4 If Push Detects Warnings

If you run force:source:push, and warnings occur, the CLI doesn’t push the source.
Warnings can occur, for example, if your project source is using an outdated version. If you
want to ignore these warnings and push the source to the scratch org, run:
sfdx force:source:push --ignorewarnings

5 If Push Detects File Conflicts

If conflicts have been detected and you want to override them, here’s how you use the
power of the force (overwrite) to push the source to a scratch org.
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_push_md_to_scratch_

org.htm
17 Salesforce Developer Experience

3.6 Develop the app

3.6.1 Create Source Files from the CLI

To add source files from the CLI, make sure that you are working in an appropriate directory.
Execute one of these commands.

apex:class:create
apex:trigger:create
lightning:app:create
lightning:component:create
lightning:event:create
lightning:interface:create
lightning:test:create
visualforce:component:create
visualforce:page:create

Consider using these two powerful optional flags:

Option Description

-d, --outputdir The directory for saving the created files. If you don’t indicate a directory,
your source is added to the current folder.
-t, --template Template used for the file creation

3.6.2 Edit Source Files

To edit a FlexiPage in your default browser—for example, to edit the Property_Record_Page
source—execute this command.
sfdx force:source:open -f Property_Record_Page.flexipage-meta.xml

If you want to generate a URL that loads the .flexipage-meta.xml file in Lightning App Builder but
does not launch your browser, use the --urlonly flag.
sfdx force:source:open -f Property_Record_Page.flexipage-meta.xml -r

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_develop.htm
18 Salesforce Developer Experience

3.7 Pull the source to keep your project and scratch org in sync.
After you do an initial push, Salesforce DX tracks the changes between your local file system and
your scratch org. If you change your scratch org, you usually want to pull those changes to your
local project to keep both in sync.

During development, you change files locally in your file system and change the scratch org us-
ing the builders and editors that Salesforce supplies. Usually, these changes don’t cause a conflict
and involve unique files.
By default, only changed source is synced back to your project.

To pull changed source from the scratch org to the project:

sfdx force:source:pull

To pull source to the project if a conflict has been detected:

sfdx force:source:pull --forceoverwrite

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_pull_md_from_scratch_

org.htm

3.8 Run tests

When you’re ready to test changes to your Salesforce app source code, you can run Apex tests
from the Salesforce DX CLI. Apex tests are run in your scratch org.
You can also execute the CLI command for running Apex tests (force:apex:test:run) from within
third-party continuous integration tools, such as Jenkins.

1. To run Apex tests from the command line:

sfdx force:apex:test:run

2. This command runs all Apex tests in the scratch org asynchronously and then outputs a job
ID. Pass the ID to the force:apex:test:report command to view the results. The results in
clude the outcome of individual tests, how long each test ran, and the overall pass and fail
rate.
sfdx force:apex:test:report --testrunid 7074C00000988ax
19 Salesforce Developer Experience

4. Use the --synchronous parameter to run tests from a single class synchronously. The com
mand waits to display the test results until all tests have completed.
sfdx force:apex:test:run --synchronous --classnames TestA

5. Use parameters to list the test classes or suites to run, specify the output format, view code
coverage results, and more. For example, the following command runs the TestA and TestB
test classes, provides results in Test Anything Protocol (TAP) format, and requests code
coverage results.
sfdx force:apex:test:run --classnames TestA,TestB --resultformat tap --codecoverage

6. Use the --tests parameter to run specific test methods using the standard notation Class.
method. If you are testing a managed package, use namespace.Class.method. If you spec
ify a test class without a method, the command runs all methods in the class. This example
shows how to run two methods in the TestA class and all methods in the TestB class.
sfdx force:apex:test:run --tests TestA.excitingMethod,TestA.boringMethod,TestB

Here’s the same example but with a namespace.

sfdx force:apex:test:run --tests ns.TestA.excitingMethod,ns.TestA.boringMethod,ns.TestB
You can specify either --tests or --classnames with force:apex:test:run but not both.
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_testing.htm

3.9 Export The Package.xml

Export package.xml file into the temporary directory. Type the commands below in the root folder
of your Salesforce DX project:

sfdx force:mdapi:retrieve -r ./temp -u {TARGETUSERNAME} -k {SFDC PROJECT

SOURCE LOCATION}\src\package.xml

where TARGETUSERNAME is the login name of Salesforce Dev/Sandb ox Org

Note:
If the project source location contains empty spaces, then ensure that you enclose the complete
path within double quotes (“”).
Unzip the unpackaged.zip file that is created from the above command and optionally delete the
unpackaged.zip file.
20 Salesforce Developer Experience

3.10 Convert Source code to Salesforce DXV

Convert the source code to the Salesforce Developer Experience project structure by running the
following command:

sfdx force:mdapi:convert --rootdir temp --outputdir force-app

3.11 Track Changes Between the Project and Scratch Org

To view the status of local or remote files:
sfdx force:source:status

3.12 Sync up
Sync the local version with the version deployed to Scratch Org for every change and test the
changes on the Scratch Org by repeating the above steps.
Once the testing is completed, we need to convert the source from Salesforce DX format to the
Metadata API format. This is done by running the following command:
sfdx force:source:convert --outputdir {OUTPUT DIRECTORY HERE}

Copy the modified metadata files from this output location to the actual source location where the
metadata files are downloaded from Dev/Sandbox Org to deploy the files to the server.

4. DX for Salesforce DevOps

DevOps can use it as a part of build automation scripts: to create and access environments, to
deploy source, to install packages, and to run tests.

4.1 Best Practices

• Version Control Setup, Integration and Support

• Keeping things simple not just improves development speed, it also makes maintenance
and training much easier

• Follow the same development flow for both new features and bug fixes

• All changes should be deployed out to your testing environments as soon as possible after
merging
21 Salesforce Developer Experience

• Branches need to be used to represent a single deliverable request

• Prefer feature based custom deployments

• Small releases are better than complex ones

• Include minimum viable number of changes in one branch and not more

• The longer a branch exists without getting merged, the greater risk for merge conflicts and
deployment challenges

• Don't automate deployments to production org

• Keep things lean to remove barriers to adoption

• Role-based production deployment with back-up

• Apex Code Coverage

• Multi-Browser Testing

4.2 Version Control System (VCS)

A VCS is at the heart of source-driven development. We need a VCS to manage and version our
source to take full advantage of what the new tools and package development offer.

• A VCS plays an integral role in the package development life cycle

• Stores all source for your packages in a source control repository, where the source of truth
is maintained. Being a single ‘source of truth’ for the team.

• Build scratch (development) orgs from that source, so you can work specifically on your
package

• It provides change tracking features to monitor what you’ve created, updated, and deleted
in the development org and makes it easy to maintain and deploy different versions of code
across test, staging and production environments

• It is easy to pull modified source down to your file system and check it into your VCS

• Provides tools to identify and resolve file conflicts

• Maintains a full audit trail for every stage of the development cycle.
• Facilitating collaboration and code review
22 Salesforce Developer Experience

5. Challenges
DevOps, as applied to Salesforce.com development is different. These are common challenges in
release management and software development

Low confidence in testing

• New and untested deployments for each and every request between environments

• Testing suffers when environments differ that result in defects and production issues

• Loss of confidence to test results when environments are different that lead to defects and
re-work

Environments not in sync

• Environments quickly get out of sync. Refreshing takes time and deployments have errors
Deployment challenges

• Manual deployments are a key bottleneck across projects and test phases

• Developers directly update environments that lead to missed deployment steps

• Future Releases that are built on an old Production refresh requires added testing and de
ployment time

Maintenance issues
• Go-Live is challenging with hundreds of manual steps

There are few challenges that DevOps teams need to consider with the Salesforce deployment
model:
• Comprehending how to merge and deploy code from one Salesforce Org to another.

• The Metadata API does not support rolling-back once the API call has been completed suc-
cessfully.

• Not all elements can be deployed using Metadata API, because either Salesforce has not
yet added those items to the Metadata API or they are configuration changes unique to each
Org.
23 Salesforce Developer Experience

6. Conclusion
Salesforce Developer Experience is a great step and will ease development on the platform. It
encourages team development and rightly so because you achieve more as a team compared to
individual.

7. About DemandBlue
DemandBlue transforms customer experiences (CX) by offering Salesforce consulting through a
unique pay-as-you-use On Demand Services model

Development &
Advisory Integration
Customization

Our Salesforce We customize We connect your

consulting teams invest Salesforce features by Salesforce instance(s)
the time and effort creating and scaling to multiple data sources
to understand your custom apps on Force. and apps to create an
business to create a com and Salesforce integrated view
successful Salesforce
strategy

Administration &
Maintenance Lightning Migration
Support

We will manage your We maintain your Our Salesforce consult-

field customization, existing applications, ing services include
page layouts, user workflows, approval seamless migration
updates, sales console, processes, user options for the switch
service console, trou- management, security from Salesforce
bleshooting and more controls, web services Classic to Lightning
etc.