Trailhead

Salesforce DX - General

Q. What is Salesforce DX?

Salesforce DX is an entirely new way to build and manage Salesforce apps across the entire software development lifecycle. It enables source-driven development of code, team collaboration with governance, and new levels of agility for custom app development on the Salesforce Platform. 

Q. What is “Source Driven Development” (SDD) and why is it important?

SDD is the phrase we are using to describe the ability for Salesforce developers and admins to manage their development processes through source code.  We are working on externalizing all of our source and configuration data so that you can create environments, build packages, and automate the whole process. This work also includes features that help you to better manage your source and synchronize source to and from Scratch orgs.

Q. What are the Key Features of Salesforce DX?

• New developer tools and environments 
• Salesforce CLI
• Scratch Orgs

Source Control & Metadata Externalization

• Expanded tooling for automation
• Source sync APIs
• Tracking changes in & out of orgs
• Org Source Shape

Developer Tools

• Introduction of Visual Studio Code Extension Pack for Salesforce DX
• Expanded support for third-party IDEs and text-editors
• Scratch environments
• Salesforce CLI: the full power of Salesforce DX via the command line, allowing developers to easily create environments for development and testing, synchronize source code, create and execute test suites, and control the full application lifecycle.
• ISV Apex Debugger for Scratch Orgs

Continuous integration (CI) & Continuous Delivery (CD)

• Bring your own CI/CD tools (e.g. Jenkins, TeamCity, Travis CI, etc)
• Test runner for automation of Apex, Selenium, and JUnit tests.
• Data loading support via CLI

Packaging and distribution

• 2nd generation packages (aka “Packaging 2,” currently in Beta)
• Packages built directly from source
• Multiple packages sharing a single namespace
• Unified deployment path for both IT and ISVs

Q. Is Salesforce DX only for ISVs? 

Salesforce DX is available for any Salesforce Platform developer.  

Q. Is Salesforce DX only for coders? How do admins and low-code developers use Salesforce DX?

Salesforce DX is for admins, QEs and developers of all levels.  Upcoming features such as the Feature Management Application can be used by admins to manage different features for their customers, and QEs can utilize scratch orgs for testing.  

Q. Can customers/partners use their existing CI & CD tools with Salesforce DX? 

Yes! If you use a different tool for CI (like Travis or Circle) you can use that with Salesforce DX.

Q. Do I have to use Github? Can I use other VCS systems? 

No, you can use any VCS system.

Q.  I want to configure Continuous Integration (CI).  How can I set up CI knowing that my User Session might expire? 

We have a specific authorization workflow, utilizing JWT, thats is ideal for CI systems.   

Q. I am an admin and have never used a command line. How hard is it to try Salesforce DX?

Trying out Salesforce DX will be easy because we provide you with all the necessary tools, documentation, and examples. However, using Salesforce DX effectively will require a fundamental paradigm shift by your developers, administrators, and release managers.

For example, an admin who is accustomed to editing everything in an org will need to shift their understanding that the source of truth now resides outside of the org, in source control.  Also, the command line might seem daunting at first, although it is not as scary as it looks once you’ve spent time hands-on.  The biggest challenge for many may be the need to become familiar with new concepts related to version control, syncing sources, etc. 

Fortunately, these are well-established industry concepts that are used by most software companies around the world. There are many resources on the Internet (tutorials, books, documentation, etc.) that are helpful. We are confident that once you start using Salesforce DX, you’ll be convinced that it’s the best way to for teams to build on the Salesforce platform. 

That being said, if your main concern is with the command line interface, the Salesforce IDE will have an embedded command line view friendly to newcomers. The IDE console will have tab-completion, prompting for each command line flag that is required, and hints for which optional flag parameters can be specified.

Q. Will there be any new Salesforce DX Trails in Trailhead?

Yes! We are excited to announced the new Trailhead trail dedicated to Salesforce DX: https://trailhead.salesforce.com/en/trails/sfdx_get_started

Salesforce DX - Scratch Orgs

Q. What is a scratch environment? How is it different from other orgs? 

The purpose of a scratch environment is to be a short lived org that is used for a specific purpose.  That purpose can be testing some code, creating an environment for CI testing, or any other reason why a short lived Salesforce environment would be needed.  It’s main difference from other environments is that is not meant to be long lasting. 

Q. How are scratch environments related to Sandboxes? Are they a replacement?

Scratch environments are created specifically for source driven development.  They should be used for development purposes in conjunction with a workspace that is sync’d with the scratch environment.  They should also be used for continuous integration (CI) use cases, where the requirement is to deploy source for automated testing. 

Scratch environments are not a replacement for sandboxes. First and foremost, Sandboxes will continue to support our current development processes that enable change sets and the ant migration tool.  Sandboxes are also extremely important in the test phases of our new source driven development process. All sandbox types can be used as part of continuous delivery (CD) use cases.  

Sandboxes should be the destination for Packages that are built from your source. Instead of deploying source to these environments, you would be executing package installations, mimicking your production deployment.  All sandbox types, from developer to full, offer the ability to act as a UAT and Staging environments of the production org.

Q. Will a scratch environment contain test data? 

Scratch environments do not contain test data upon creation.  Post-creation, you have the ability to use our CLI to automate data loading and data extraction. 

Q. Do person accounts work with scratch orgs? 

Scratch orgs derived from developer edition templates do not support person accounts. However, scratch orgs based on other editions that support person accounts (e.g. enterprise editions) works fine with this feature.

Salesforce DX - Pricing

Q. What will Salesforce DX cost? 

All partners get 100 Salesforce Limited Access - Free user licenses to access the Developer Hub. Starting Apr 1st, 2018, AppExchange Partners will receive 40 active and 80 daily scratch orgs, and AppExchange Premier partners will receive 150 active and 300 daily scratch orgs. Additional scratch orgs above the tier allocations may be purchased.

Q. Do I have to buy version control? 

Bitbucket.com has free private code repositories for teams of up to 5 people. Read more about Bitbucket repository pricing. Github.com is free for public repositories only. Github private repository plans start at $7/month for unlimited repositories. Read more about Github repository pricing. 

Packaging 2 - General 

Q. How is Salesforce DX planning to improve packaging?  

The changes are going to come in two waves: 

1. Enhancements to current managed packages, mainly along improved API coverage and end-to-end CLI.
2. Packaging 2 is going to reimagine app distribution over the Salesforce Platform. These changes are going to be rolled out over multiple releases, and is currently in Beta.

Q. What is Packaging 2?  

Packaging 2 has the following advantages over the current managed package technology: 

1. Multiple packages can be developed within the same namespace.
2. Sharing code becomes much easier. Apex in public classes can be shared across packages unlike the current behavior where any shared code must be placed in global apex, making refactoring difficult.
3. Makes end-to-end team development and testing a much better experience.
4. Development along multiple branches will be supported. So, one team can work on Summer ’17 features while the main team is working on Spring ’17 features. 
5. Manageability is something that the developers can control as opposed to current system that is hard-coded and controlled by salesforce. 
6. Developing, testing and installing extension packages is made simpler.

Q. Are managed packages going away? 

No. They will in fact be enhanced with better CLI and API capabilities. Having said that, Packaging 2 will offer much richer capabilities, encouraging you to move over to them from managed packages. The plan is to offer a compelling feature set that naturally motivates you to move over to Packaging 2 rather than force you to stop using managed packages. We will provide capabilities to ease the migration from managed packages to Packaging 2 and more information on migrating from one to the other.

 Q. Which packaging commands are going to be made available in the CLI?

The plan is to provide end to end CLI support for managed packages (and unmanaged packages, where applicable)  These CLI commands will be offered over multiple releases. Please review the Salesforce DX CLI Command Reference to see which commands are available as of the Winter ‘18 release.

Q. Does Packaging 2 fix or replace Beta Packages? 

It will provide a much better experiences for developing beta packages.   

Q. When is Packaging 2 going to be made available?  

Packaging 2 is going to be rolled out over multiple releases starting with open beta in Winter ‘18, and possibly GA in Summer ‘18.

Q. Will I be able to migrate my current managed packages to Packaging 2, or do I have to start from scratch?

We will have a comprehensive migration path to migrate legacy managed packages to 2nd generation packaging.