At their massive Dreamforce conference, cloud leader Salesforce.com unveiled Salesforce DX: a new model for building and deploying applications to their platform. Salesforce DX embraces concepts—such as source control management, continuous integration, and scripting—that until now, have been somewhat foreign to many Salesforce developers. InfoQ spoke to VP of Product for Salesforce DX, Wade Wegner, for all the details.
InfoQ: Describe for us the broader goal of Salesforce DX. Is this about expanding the types of applications that are a fit for Salesforce, and bringing modern software development practices to the platform?
Wade Wegner: Salesforce DX defines an entirely new way to develop, deploy, and upgrade Salesforce apps across their entire lifecycle, bringing together the best of Force.com and Heroku developer experiences, to enable source-driven development of code, team collaboration with governance, seamless promotion of code from development to production, continuous integration with automated testing, and support for third party developer tools in the application lifecycle. With Salesforce DX, developers can achieve new levels of agility for custom app development on the Salesforce platform.
InfoQ: What are the specific Salesforce artifacts that a developer would store in a GitHub repo? Does this service only target Salesforce developers writing Apex?
Wegner: As part of Salesforce DX, we continue the journey to fully externalize the source and metadata in your Salesforce environment as artifacts in source control so that you can use a true source driven development style. In addition to source code metadata, we capture things like test configuration, test data, and Salesforce org shape (i.e. edition, feature, and preferences).
Salesforce DX is about a lot more than just metadata and source in an org. A growing number of enterprises are developing distributed, composable applications that combine Salesforce code with microservices developed on open languages and frameworks. Salesforce DX is specifically designed to support these distributed application designs. Our continuous delivery and continuous integration tools, built on the Heroku platform, are agnostic to the language or languages that are used to write these custom apps. With Salesforce DX we have added support for Salesforce applications and Apex to these tools.
InfoQ: Heroku Flow plays a big part in Salesforce DX. Can you describe what this service is, and how it's used both inside and outside of Salesforce?
Wegner: There are four key components to Heroku Flow, three that have been out in GA on the Heroku platform since early 2016, and one that is entirely new and launching into beta this month. The existing Heroku Flow services include:
- Heroku Pipelines: Pipelines is a way to organize a group of Heroku apps sharing the same codebase into review, development, staging, and production environments to support, manage and visualize continuous delivery. Promoting tested code from one stage to the next can be done manually or automatically and is nearly instantaneous, since the compiled artifact is promoted to the next stage.
- Review Apps: Review apps are a way to propose, discuss, and decide whether to merge changes to your code base. For Heroku apps connected to GitHub, Heroku can manually or automatically spin up a temporary test app on a unique URL for every opened pull request (PR). The temporary app is auto-updated on every commit, so instead of guessing about what the code might do, reviewers can actually try the changes in a browser. Merging the PR destroys the review app and, when used with pipelines, automatically promotes the code to staging. In the world of Salesforce DX, the role of review apps is filled by scratch orgs.
- Github Integration: With Github integration, you can connect your GitHub repo to a Heroku app to either manually or automatically deploy a particular branch on every GitHub push. For every deploy you can see the diff between the current release and the previous commit in the app’s Activity tab in the Heroku Dashboard, so you’re never guessing what code is on the app. We are extending this Github integration for Salesforce apps as part of Salesforce DX.
The newest addition to Heroku Flow is Heroku CI, a new embedded Continuous Integration offering that is being simultaneously launched into beta on the Heroku platform and into developer preview as part of Salesforce DX. Heroku Flow already can be integrated with third party testing tools such as Jenkins, but Heroku CI offers a new alternative that can complement or take on the primary role of running automated tests against your code.
InfoQ: "Scratch orgs" are new in Salesforce with DX. What's their purpose, and how does this impact a Salesforce developer's current workflow?
Wegner: Scratch orgs are a new type of Salesforce environment, a source-driven and disposable deployment of Salesforce code and metadata. Scratch orgs are fully configurable, allowing developers to emulate different Salesforce editions with different features and preferences, playing a critical role in driving developer productivity and collaboration during the development process. Developers can spin up scratch orgs as part of their development process when they create a branch to develop features, and they can share these scratch orgs with their collaborators and peers as part of the review process. Scratch orgs can also be used as part of automated testing and the implementation of a full continuous integration suite.
InfoQ: You've added a new CLI that claims to work across the platform. Is this just for custom code scenarios, or would I manage other aspects of Salesforce organizations via the CLI? Who do you envision using this?
Wegner: The Salesforce DX command-line interface (CLI) is one of the most exciting additions for the Salesforce developer. It's built on the Heroku CLI, and provides a way for developers to take advantage of all our APIs. In the past, these capabilities lived across a number of different tools (e.g. Salesforce workbench, Force.com CLI, and more).
The CLI becomes the principal way in which developers will interact with the Salesforce org. You can use it to create scratch orgs, push and pull source and metadata into the org, and even perform operations that affect metadata in the org — for example, assigning a permissions set for an app or executing anonymous Apex.
The CLI also provides ways to make DevOps easier with Salesforce. You can use the CLI as part of build automation scripts, creating environments from source and running all of your tests.
Our API first approach is extended to the CLI, and over time we will bring more and more capabilities for Developers to the Salesforce DX CLI.
InfoQ: Walk us through a developer flow based on Salesforce DX. What steps and technologies are in play from application bootstrapping through deployment?
Wegner: One of the key principles in designing Salesforce DX is to give teams the flexibility to define the methodology that is right for them. However, Salesforce has made a source-driven development approach the center of our implementation because we believe this gives customers the best opportunity for success.
It starts by defining a version control strategy. Salesforce DX can support different VCS options, but we encourage you to adopt a VCS as the foundation for your development processes. The source of truth for your app is no longer the org, it's the version control system.
The next step is to understand your environments. The new scratch org makes it easier for developers to build their apps and automate continuous integration and delivery, all from the CLI. The scratch org allows developers to develop using local source, run all their tests, and deliver confidence before they commit back into VCS.
Once updates are back in VCS, developers will be able to use standard web hooks to initiate build automation and continuous integration (CI), whether it's the Salesforce solution using Heroku Pipelines or a 3rd party tool like Jenkins or TeamCity.
Along the way, we are giving developers the ability to use the tools of their choice. The CLI helps to remove the complexity of interacting with Salesforce orgs, meaning you don't have to use specialized tooling — you can use Vim, Sublime, Visual Studio Code, Atom, or any text editor for writing your code.
InfoQ: What sort of things are baked into the new Eclipse-based IDE that you're offering to developers? How does this differ from previous IDE integrations?
Wegner: The Force.com IDE, our Eclipse-based tooling, has long been our premier Salesforce developer tool. The new Force.com IDE 2 continues to offer the widest range of support for all the metadata types available to Salesforce, from Apex to Workflow. We've worked hard to bring many powerful new capabilities including: language services, full support for Lighting development, and the ability to load declarative builders directly into the IDE.
As part of Salesforce DX, all your metadata is externalized in source control. By deriving your Eclipse project directly from that same source control, we are able to get a complete view of the metadata. This facilitates smarter analysis because we know all of your Apex classes, all of your custom objects, all of your Lightning components, etc. Previously, in the old Force.com IDE, the users could, and frequently would, select only a subset of the metadata to import into their Eclipse project. This partial view limited the ability of the IDE to offer smart analysis since it was missing vital pieces of information.
The real innovation for us, however, is that the new Eclipse plugin is built on the CLI. This not only accelerated our work, but means that all the innovations we bring to the CLI also come to the IDE. This pattern is something we're encouraging all of our tooling partners to adopt, making it easier to create great developer experiences in many different tools.
InfoQ: What do you say to someone who see Salesforce as a place for "point and click" development only?
Wegner: Our vision for Salesforce DX spans the entire spectrum of customer trailblazers on the Salesforce platform, from programmatic developers to Salesforce admins and business users that design and deploy their Salesforce apps via a low code “point and click” model. To lay the right foundation for Salesforce DX and meet the most rigorous requirements from large ISVs, SIs, and enterprise customers, we kicked off this initiative focused on CLI-driven and highly scalable custom application development. As we bring Salesforce DX to market over the next year, our attention has already turned to how to apply the right levels of abstraction and user-centered design to expose the core advantages of Salesforce DX to admins and business users via visual flows and familiar admin constructs, such as change sets. Stay tuned for more on this topic in the releases ahead.
InfoQ: How can developers learn more about Salesforce DX?
Wegner: A great place to start is our developer page on the web: https://developer.salesforce.com/platform/dx.
We will post updates to that page as we get closer to our public beta and GA next year, and you can sign up to be on the list of interested developers to be amongst the first to know about more details. Don't forget to also watch the Developer Keynote from Dreamforce 2016 with our President of Technology, Srini Tallapragada.