Salesforce DX Platform Development

Salesforce DX is a new integrated experience designed for high-performance, end-to-end agile Salesforce development that is both open and flexible.

Before Salesforce DX, all custom objects and object translations were stored in one large Metadata API source file.

Salesforce DX solves this problem by providing a new source shape that breaks down these large source files to make them more digestible and easier to manage with a version control system.

2017-07-06 01_31_57-workspace - Force.com IDE

A Salesforce DX project stores custom objects and custom object translations in intuitive subdirectories. This source structure makes it much easier to find what you want to change or update. Once you have developed and tested your code you can then convert the format of your source so that it’s readable by the Metadata API, package it and deploy  it.

aplx

This is a complete shift from from monolithic, org-based development to modular, artifact-based development while also enabling continuous integration (CI) and continuous delivery (CD). This means development teams can develop separately and build toward a release of the artifact, and not a release of updates to the org.

This will be a working post as I continue to go through the release notes and work with the new platform tools.

Resources

Get Started with Salesforce DX

Salesforce DX Developer Guide

Salesforce CLI Command Reference

Install the Tools:

DX CLI – install here

Force IDE 2 – install using this link and install preequesties Java kit here

Dev Hub (Trial Org) – sign up for a dev hub trial

Create your directory

Open up Git

Cd c:

Mkdir dx

Cd dx

Mkdir projectname

Cd projectname

 

Configuring your DX project

Salesforce DX projects use a particular directory structure for custom objects, custom object translations, Lightning components, and documents. For Salesforce DX projects, all source files have a companion file with the “-meta.xml” extension.

When in the project directory:

sfdx force:project:create -n projectname

ls

you will see a few files.

The project configuration file sfdx-project.json indicates that the directory is a Salesforce DX project.

If the org you are authorizing is on a My Domain subdomain, update your project configuration file (sfdx-project.json)

“sfdcLoginUrl” : “https://somethingcool.my.salesforce.com”

Package directories indicate which directories to target when syncing source to and from the scratch org. Important: Register the namespace with Salesforce and then connect the org with the registered namespace to the Dev Hub org.

Creating your VCS Repo

You can now initiate a git repo and connect it to bitbucket or github.

create bitbucket / github repo

git init
git add .
git commit -am ‘first dx commit’
git push -u origin master

if you go to your repo in the browser you should see the dx json config file and sfdx structure.

cd projectname

Creating a Scratch Org

sfdx force:org:create -s -f config/project-scratch-def.json -a ipfsDXScratch

You don’t need a password but can add one using force:user:password:generate

You can also target a specific dev hub that isnt the default.

sfdx force:org:create --targetdevhubusername jdoe@mydevhub.com --definitionfile my-org-def.json --setalias yet-another-scratch-org

–targerdevhubusername to set a dev org not the default

The Scratch Org

You can have

  • 50 scratch orgs per day per Dev Hub
  • 25 active scratch orgs,
  • They are deleted after 7 days

The scratch org is a source-driven and disposable deployment of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with different features and preferences. And you can share the scratch org configuration file with other team members, so you all have the same basic org in which to do your development.

The project.json file is what makes the project and scratch org configurable. You can now define what type of org, permissions and settings you want to build and test in. It is a way to build and test with certain platform features, application settings and circumstances while also being able to version and have source control.

This also enables continuous integration because you can test against a use case in one of the scratch orgs and see the impact based on the configuration or by importing data from  the source org. Once bulkified and tested it can be pushed back into the source org.

Scratch orgs drive developer productivity and collaboration during the development process, and facilitate automated testing and continuous integration.

Use many scratch org config files – name them . They are the blueprint for the org shape.

Ethereum-scratch-def.json

Production-scratch-def.json

devEdition-scratch-def.json

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

Here is a complete list for the Features and Preferences that you can configure.

Authorizing your DX Project

sfdx force:auth:web:login --setalias my-sandbox

This will open the browser and you can login

sfdx force:org:open  --path one/one.app

For JWT and CI

sfdx force:auth:jwt:grant --clientid 04580y4051234051 --jwtkeyfile /Users/jdoe/JWT/server.key --username jdoe@acdxgs0hub.org --setdefaultdevhubusername --setalias my-hub-org --instanceUrl https://test.salesforce.com

Creating

Create a Lightning Component / Apex Controller / Lightning Event at command line:

sfdx force:lightning:component:create -n TokenBalance -d force-app/main/default/aura

 

Testing

sfdx force:apex:test:run --classnames TestA,TestB –-resultformat tap –codecoverage

Packaging

First convert from Salesforce DX format back to Metadata API format

sfdx force:source:convert --outputdir mdapi_output_dir --packagename managed_pkg_name

Deploy to the packaging org

sfdx force:mdapi:deploy --deploy_dir mdapi_output_dir --targetusername me@example.com

Creating a Beta version

  1. Ensure that you’ve authorized the packaging org.
  2. sfdx force:auth:web:login --targetusername me@example.com
  3. Create the beta version of the package.
  4.  sfdx force:package1:version:create --packageid package_id --name package_version_name

Managed-Released Version

Later, when you’re ready to create the Managed – Released version of your package, include the -m (–managedreleased true) parameter

sfdx force:package1:version:create --packageid 033xx00000007oi --name ”Spring 17” --description ”Spring 17 Release” --version 3.2 –managedreleased

After the managed package version is created, you can retrieve the new package version ID using force:package1:version:list

Installing a package

sfdx force:package:install --packageid 04txx000000069zAAA –targetusername –installtionkey

sfdx force:package1:version:list --

(use a bitcoin/ethereum/token address as the package installation key)

Check to see if has paid and if it has, it installs.

Push and Pull

sfdx force:source:push

This is used to push data from your project to a scratch org

It will push the source code to the scratch org you have set as the default, or you can specify an org other than the default by using

–targetusername

-u

.forceignore – Any source file or directory that begins with a “dot,” such as .DS_Store or .sfdx, is excluded by default.

sfdx force:source:pull

This is used to pull data from your scratch org to your project

Setting Aliases

sfdx force:alias:set org1= name org2= name2

To remove an alias, set it to nothing.

 sfdx force:alias:set my-org=

Listing your Orgs

sfdx force:org:list

(D) points to the default Dev hub username

(U) points to the default scratch org username

Retrieving and Converting Source from a Managed Package

Working with Metadata has usually required a tool like ANT. Now you can retrieve unmanaged and managed packages into your Salesforce DX project. This is ideal if you have a managed package in a packaging org. You can retrieve that package, unzip it to your local project, and then convert it to Salesforce DX format, all from the CLI.

Essentially you can take your existing package and re shape it into a Salesforce DX Project format

Custom Object with subdirectories:

businessProcesses

  • compactLayouts
  • fields
  • fieldSets
  • listViews
  • recordTypes
  • sharingReasons
  • validationRules
  • webLinks

 

Mkdir mdapipkg

sfdx force:mdapi:retrieve -s -r ./mdapipkg -u username -p packagename

sfdx force:mdapi:retrieve -u username  -i jobid

Convert the metadata API source to Salesforce DX project format.

sfdx force:mdapi:convert –rootdir  <retrieve dir name  --outputdir

Additional Things

To get JSON responses to all Salesforce CLI commands without specifying the –json option each time, set the SFDX_CONTENT_TYPE environment variable. export SFDX_CONTENT_TYPE=JSON

Log Levels  –loglevel DEBUG

ERROR WARN   INFO    DEBUG TRACE

To globally set the log level for all CLI commands, set the SFDX_LOG_LEVEL environment variable. For example, on UNIX: export SFDX_LOG_LEVEL=DEBUG

One thought on “Salesforce DX Platform Development

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s