Salesforce is in a transition from great CRM product to a full-fledged enterprise platform. Large amounts of data, lots of developer activity, an online marketplace, and a fanatical partner community could create the right environment for an explosion of new enterprise applications. Salesforce has announced some powerful new tools that make their platform more attractive to traditional enterprise developers. One major part of this effort is Salesforce DX, a Command Line Interface that hopes to address some of the gaps between traditional enterprise software development and the Salesforce toolset. This is a big opportunity for ISV’s and Salesforce Administrators alike to build some insanely great enterprise applications that leverage these new capabilities. This blog discusses how DX helps enable the platform transition at Salesforce.
Metadata Silos Vs. Enterprise Projects
But first, let’s spend a minute looking at some of the existing problems that Salesforce developers have. Underneath all of the data in your Salesforce account is the metadata: all of the customizations and code that makes your Salesforce account unique. When a new application is built, it starts out as metadata. If you dump the metadata in your Salesforce account, you will find it organized into over 100 silos. Each type of metadata (for example, Custom Objects, or Page Layouts) will be delivered in a folder.
It turns out, this is probably not what a seasoned Enterprise developer was hoping to see. For example, all of the Apex Classes being used in the org are stored in a single folder. All of the Custom Objects are in another folder. You can see their names, but there isn’t any structure to the org. Developers would rather see multiple metadata types organized into folders by application or project. This groups related functionality together and separate each project by team and function. Enterprise developers also expect version control, agile release cycles, code difference reports, and online repositories for their projects.
What About Packages?
Currently Salesforce developers groups related functionality together with managed or unmanaged packages. Unmanaged packages aren’t really what enterprise developers are looking for. They are basically a way to move and share metadata assets. When you load an unmanaged package into the org, all of the assets in the package flow into the sea of unpackaged assets where they can be freely edited. But unmanaged packages are not really upgradeable, and they can’t be used on the AppExchange anymore.
Managed packages were largely developed for the ISV community to publish AppExchange applications. They can be upgraded but not edited. Even the publisher of the package faces many restrictions on what can be changed. This is to protect Salesforce customers that are using the applications from data loss. Also, the Apex Classes in a managed package are obscured to protect the IP Rights of the publishers. Managed packages are great at what there were designed to do, they aren’t really what an enterprise developer is looking for publish applications into their own Salesforce account.
Salesforce DX Second-Generation Packages
One of my favorite new Salesforce DX features is Second-Generation Packages. There are new types of managed packages, unlocked packages, and locked packages. In the old model, you used a single developer org to create a managed package, and then that org was the host for all package customizations. Now with the new Dev Hub model, a development team can create an unlimited number of these new package types and quickly test them out in a Scratch Org. Each package is built from scratch with metadata assets and code stored in a developer project on your local machine. The application can be easily tested against multiple Salesforce org with the new Org Shape capabilities.
The new locked and unlocked packages can be created with or without a namespace. An unlocked package without a namespace is similar to the old style of unmanaged package. But a locked or unlocked package with a namespace can be upgraded like a managed package and also edited like an unmanaged one. This combines the best of both worlds. The option to lock a package will appeal to enterprises that want to prevent tinkering after install.
Second-Generation Packages should go a long way to opening up new models for development and deployment. Now a large company with multiple projects in development can use packages to make development and deployment easier, track changes more clearly, and keep customizations more organized. Administrators won’t have to wade through the sea of unpackaged data to see what is in their Salesforce org.
The Setup Menu Vs. Source Driven Development
Another issue for developers and administrators alike is the Setup Menu. In the olden days, the Setup Menu was the way everyone configured and administered Salesforce. That was where you created new objects, added groups and roles, built email templates, and controlled everything for your users. And as Salesforce expanded, the Setup Menu became more and more complex. And there is nothing wrong with this: many smaller companies can do everything they need with the Setup Menu.
But larger companies need control and visibility. How has the org changed over time? What are the differences between Sandbox and Production? Who made the changes? Did somebody test this? What is the chain of custody for production assets? Do we need better compliance documentation? What about regulations like HIPAA, SOX, FISMA, PCI-DSS, GLBA, and GDPR? Big companies don’t want to hear that someone went into the Setup Menu and changed some stuff and now it’s working again. They need better answers.
The Setup Menu causes similar problems for enterprise developers. They are used to source driven development environments, where they can clearly see every difference over time for the projects they are working on. The code repository is the source of truth for the application they are working on. The customizations coming out of the Setup Menu control vital parts of how a Salesforce application behaves, but they aren’t part of the development process.
Salesforce DX Developer Projects
Salesforce DX defines a file format and folder structure for developer projects on the local machine. Developers can use the Salesforce DX Command Line Interface to clone these projects from repositories or make code commits across a team. They can add frameworks for Apex Classes, Lightning Components, and Visualforce pages. Developer projects are the new foundation for source driven development on the Salesforce platform.
Developers can push their projects to disposable Scratch Orgs. This follows the traditional “compile and test” model that engineers are familiar with. A developer can also make changes to their project with the Setup Menu. These changes can be pulled back and incorporated to the local developer project. In this manner, changes can flow back and forth between the developer project and the Scratch Org. This capability merges traditional software development on the client with Setup Menu changes in the cloud.
All Together Now
Developer Projects will provide the familiar source-driven tools that enterprise developers are looking for. And Second-Generation Packages will be the vehicle to deploy and distribute these projects. Salesforce DX is just getting started, but the technology is already making the Salesforce platform more suitable for enterprise application developers. I will be writing a follow-up blog about how source driven development with Salesforce DX interfaces with change and release management and the Metadata API. Until then…
Metazoa was founded in 2018 by key members of DreamFactory Software. Metazoa purchased the rights to the original Snapshot product from DreamFactory, and subsequently released a major upgrade. Our team is pleased to continue working together and taking care of the customers we love, both old and new.
Designed for Salesforce administrators, Snapshot is the ultimate tool for org cleanup, reporting, auditing, comparison and lifecycle management. Features include metadata migration from sandbox to production, reporting on compliance and security, and Salesforce DX compatibility. Snapshot is available as a managed package on the AppExchange.