What is Salesforce DX?

The term Salesforce Developer Experience (DX) encompasses both a set of tools and new features that affect the app development lifecycle. Salesforce DX introduces a new development paradigm that shifts the center of your world from monolithic, org-based development to modular, artifact-based development. This model streamlines the entire development life cycle, with benefits like:

• Improving team development and collaboration.
• Facilitating automated testing and continuous integration.
• Making the release cycle more efficient and agile.

Salesforce DX isn’t a magic bullet!

Salesforce DX isn’t a magic bullet that will fix every challenge development team has with organizing change and managing releases. In their current form, the tools related to Salesforce DX will be easier for members of your team that can work with command line interfaces (CLIs) or integrated development environments (IDEs).

• In a traditional Salesforce development lifecycle, app builders use sandboxes to create and test changes. Often, for teams in the middle of a project, the ‘source of truth’ might really be whichever environment contains the latest, stable build of their project about to be pushed into the next higher environment. For another team of developers, their source of truth may or may not be in the same sandbox(es).
• Instead of piecing together the state of various environments to get the latest versions of code or metadata, your team can get the latest versions from a centralized source control system, like Git or Subversion. This style of managing development artifacts (i.e. code and other customizations) is called source driven development.
• Shifting to source driven development won’t eliminate conflicts in code or metadata, or change the need to communicate clearly across teams. But it does put the burden of organizing, managing and resolving changes into source control systems, which are built to do this efficiently. Source driven development can also give you and your team greater visibility (and audit history) into the changes made to your org—whether in code or configuration—and better ways to undo changes that have negative impacts.

A common usecase : 

If we want to share a particular application with others, one of the fastest ways to do this was to create an unmanaged package. But this also meant we needed to keep track of the login to that org if we wanted to ever work with that package again, and also remember what package went with that org(because any changes in the package can be done only from the org where it is created).

But Salesforce DX make things easier for us. When we need to create an unmanaged package to share something, we convert that same package into a Salesforce DX project and store it in source control. If we want to make changes, we can quickly spin up a temporary environment (called a scratch org), make our updates, sync our changes back to source control, spin up another scratch org, push our updated source to the new org and test out our changes. If we’ve made an error in my updates, correcting and testing multiple versions of an app takes minutes, not hours or days.

 

Let’s take a closer look at three key pieces of the Salesforce DX toolset: the Salesforce CLI, the Dev Hub, and scratch orgs.

Salesforce CLI

Wouldn’t it be better to have an application with a UI? That would help more people use Salesforce DX. Also, then we wouldn’t have to remember all those different commands and parameters.

Some of the reasons are :

• Tying Salesforce DX to a specific UI would limit how you can benefit from Salesforce DX. The Salesforce CLI does a ton of heavy lifting for you, like handling the communication to your different Salesforce orgs in an standardized way. By exposing that power in a CLI tool, you can leverage these functions with the different tools you or your team want to use — like a shell script, a continuous integration system, or the IDE of your choice.
• A UI can increase how efficiently you work with a system—to a point. But with all the different options for how you may want to use Salesforce DX, trying to tie everything back to a single UI could become quite overwhelming. With the complexity of many systems today, CLIs are often one of the few common ways developers work.

People often think that the Salesforce CLI can only be used with Salesforce DX projects – which isn’t true.The Salesforce CLI is, as the name says, a command line interface that enables you to run numerous tasks on your Salesforce environments. A major portion of the current functionality is targeted at elements that were introduced with Salesforce DX.

Dev Hub

If you try to just install the Salesforce CLI and run Salesforce DX commands, you’ll find quite a few commands will first need you to authenticate into a Dev Hub. This functionality is what allows you and your team to create and manage temporary environments called scratch orgs.

You can turn on Dev Hub functionality in your Production org. Under Setup > Dev Hub, you’ll see two toggles. The first one will enable the Dev Hub functionality, and the second is related to enabling developer controlled packaging. Once you enable Dev Hub capabilities, you cannot undo the change— keep this in mind when enabling this functionality in Production.

Scratch Orgs

Scratch orgs are one of the biggest changes (and gifts) Salesforce DX brings to your development team. These temporary Salesforce instances are designed to allow you to easily and quickly build and test changes. They can last anywhere from 1-30 days and the default lifespan is 7 days. Scratch orgs can be created in minutes and they expire without any additional management from a team member.

Scratch orgs, though amazing, will not replace your need for sandboxes.

Scratch orgs can be a great alternative or complement to the developer sandboxes, which may get crowded during the initial stages of app development. But scratch orgs won’t perfectly mirror your production environment. They’re also not the place for end-to-end integration testing, testing with large data volumes, user acceptance testing or training. These things can only be done in the sandboxes.

 

Set up our Salesforce DX environment and do some hands on

• Install Command Line Interface(CLI)
  • after installation, open cmd as Run as administrator
• Log In to the Dev Hub using the command
  • sfdx force:auth:web:login -d -a DevHub
  • -a is used to create an alias DevHub and -d is used to make this the default org.

• Take a look at all set of available commands by typing
  • sfdx force –help
• For doing hands on create a directory and download a project from GitHub
  • mkdir my_sfdx_project – creating a directory
  • cd my_sfdx_project – going into the directory
• Next, use this command to clone the app repository:
  • git clone https://github.com/forcedotcom/sfdx-dreamhouse.git
• Next, open the directory:
  • cd sfdx-dreamhouse

• Cloning the repository pulls all the source code into your local file system. But before you start editing, you first create your own branch. This is a best practice as defined by GitHub Flow, because it helps ensure your Master branch is a clean and production-ready version of your code.

• Create a branch for your project
  • git checkout -b my_branch
  • Now that you’re working in your own branch, it’s easy to submit updates to your team later on.
• Use the following command to create the scratch org, set it as your default, and give it an alias:
  • sfdx force:org:create -s -f config/project-scratch-def.json -a “default scratch org”
  • Notice that we didn’t get a password. This is because with Salesforce DX we use cached authentication tokens.
• Let’s try out this. Enter the following command
  • sfdx force:org:open
• Push the local source to the scratch org with this command
  • sfdx force:source:push

• At this point we’re close to being able to run the DreamHouse app. But when you look at the source that was pushed to the org, you see that the app uses a permission set to provide access. Before we can access the app, we need to assign that permset using the CLI.
  • sfdx force:user:permset:assign -n Dreamhouse
• We don’t have any of the DreamHouse app data in the org. Luckily, we do have sample data in our repository.Let’s use the CLI and the SObject Tree API to import this data into the org.
  • sfdx force:data:tree:import –plan data/sample-data-plan.json

We have fully set up and configured our project, we are ready to begin the development. We will now open the org and check out our Dreamhouse application.

Open the scratch org with sfdx force:org:open command. Notice, that you don’t have to login. Open Dreamhouse app from the app launcher. We can see the sample data that we have input earlier by clicking on different tabs.

 

We have used Salesforce DX to create our development environment and it was much simpler and less time taking than the process which we use now. We can quickly spin up the scratch org and do development and testing of any particular module in our project.

Unlocked Packages

The last part of the process is packaging. All of us are aware about managed and unmanaged packages that we use for packaging of our code. Both methods have some advantages and disadvantages. Unlocked packages have taken best from both the methods.

Unlocked packages allow you to decide what pieces of metadata should be in a package (hence the name). This means you can experiment with how you want to define packages, as well as update and change your packages into the future. The process of adopting unlocked packages will have overlap with the process of adopting source driven development. Identifying potential packages within your production environment is similar to deconstructing your org into modular pieces for source control.

Best practices around developing packages are still evolving. The road to adopting packages, and breaking your org into modular units for source control, will require flexibility and some trial-and-error. You’ll need to be willing to experiment and spend meaningful time analyzing your experiments.

For more detailed information please check SFDX Trailmix