For years, many of us have been looking for shortcuts through the Salesforce application lifecycle, so that we can use continuous delivery to develop packages for the AppExchange.
The lifecycle architects at Salesforce took a long look at the paths we were forging for ourselves, and they are now paving the way for source-driven development and continuous delivery.
#safeharbor – This article may contain forward-looking statements that involve risk, uncertainties, and assumptions. Any unreleased services or features referenced in this article are not currently available and may not be delivered on time or at all.
The easy way is to use the Salesforce builder interfaces to create apps with “Clicks Not Code”. It’s actually amazing how many truly useful apps can be created without writing a line of source code yourself!
If you need to push the envelope, Salesforce has always been an able-if-spartan coding platform. We have the necessities of life: development environments, code editors, unit tests, detailed logging, and deployment tools. As a bit of icing, there are also plugins for niceties like static analysis.
Until now, it has also been a do-it-yourself exercise to connect the dots and standup a continuous delivery system.
Continuous Delivery
We might not want to deliver a new version of our packages to all of our production subscribers every day, but we need to be ready to deliver whatever has been done to date whenever we decide to deliver it. Staying release ready keeps us honest, and neatly avoids having a dozen partially-done items, but nothing ready to deliver.
A continuous delivery system is part pipeline and part mobius strip. Each batch of deliverables flows through the pipeline and circles back to the beginning.
On some platforms, the ideal batch size is one. While such a thing is achievable on the Force.com platform, it may be some time before it’s the status quo. (Hope springs eternal.)
The Four Stages
The key DevOps stages are: Plan, Build, Release, Operate.
- For more on the DevOps lifecycle, see From Waterfall to Mobius Strip.
Several platform changes are either available now or underway which speak to all four phases. (Yay!)
- Build
- Scratch Orgs
- Package Modules
- Release
- Scripted Push Upgrades
- Operate
- AIP Support Tools
- Feature Enablement
- Activation Metrics
- Build and Release
- NextGen Packaging
Scratch Orgs – Build
To keep packaging orgs pristine, most developers create changes in another environment before deploying the tested version for packaging.
- Today, developers use Sandboxes, Developer-Edition orgs, or Trial orgs as development and testing environments.
- In early-to-mid 2017 (#safeharbor), Salesforce DX will let developers automatically create “scratch orgs” modeled from a branch in source control. When the branch is merged back into the mainline, the scratch org expires.
- Scratch orgs will also be supported by the Heroku Flow framework, which streamlines delivery of updates from development to production, combining the best of the Salesforce and Heroku developer experiences.
- Other solutions, like Jenkins and TeamCity, may also be used with scratch orgs. (Double-yay!)
- Scratch orgs minimize metadata transfer with the VCS by syncing changes on demand.
- For managed package development, scratch orgs support namespaces (like branch orgs).
- The metadata source tree is more flexible, allowing, for example, separation of test classes from classes under test.
- Large metadata components are being decomposed. For example, individual fields can be changed without transferring the entire custom object documents
With scratch-orgs, developers will have a first-class environment strongly tied to the version control repository. Version control becomes the source of truth.
You should let the “source of truth” bit sink in. It’s much like saying: “Okay, okay, we get it, Galileo: The earth revolves around the sun.”
Package Modules – Build
Often, larger applications are segmented into a base feature set and one or more extended feature sets. Each feature set can be organized into a package.
- Today, one namespace is assigned to one package in one packaging org. (There can only be one.) When you need is a base and an extension package, each package must be maintained in its own org.
- In mid 2017 to early 2018 (#safeharbor), multiple packages will be able to share the same namespace in the same packaging org, and then be installed together in an “app bundle”.
- Essentially, the base and extension packages will co-exist in the same packaging org.
With package modules, we can better manage dependencies between related packages, and grow applications more easily.
Scripted Push Upgrades – Release
An AppExchange app is also called a package, and platform deployments center around delivering packages.
- Prior to Winter ’17, packages were created through a point-and-click user interface. Packaging required human intervention (or utilizing player-piano UI script).
- As of Winter ’17 (now), we can upload packages through the Tooling API, which means it can be scripted and made part of continuous delivery automation.
- Prior to Winter ’17, we could also step through a UI to schedule push upgrades to sandbox or production orgs.
- As of Winter ’17, we can use the Enterprise API to create upgrade requests that can be scheduled by partners or subscribers. A packaging command line interface is also currently in dev preview.
- Available as of Winter ’17:
- Package Upload API
- Package Push Upgrades API
- Customer-Partner Interactions During Push
- Notify Partners on Packaging Error
- Available in Winter ’17 Developer Preview:
- Packaging Command-Line Interface – Upload, Install
With scripted push upgrades, we can streamline deploying changes from development through to the packaging orgs. We can also schedule upgrades for predefined groups of customers, reliably and automatically.
App Innovation Partner Support Tools – Operate
Using the LMA Subscriber Console, App Innovation Partners can login to licensed subscibers (when access is granted), to help determine problems and adjust protected custom settings.
- As of Winter ’17, ISV/AIPs can view obfuscated code in subscriber orgs with login as.
- An ISV/AIP Customer Debugger is in Winter ’17 pilot.
With AIP support tools, we can more easily diagnosis and correct issues with advanced features.
Feature Enablement – Operate
- Deploying a new version often means releasing new features.
- With Feature Enablement, we will be able to treat an app as a feature set, and separate deploying a new version from activating new features.
- Using a Feature Console, subscribers will be to activate features in their own org (think Critical Updates).
- AIPs will also be able to activate features remotely through a Feature Management Application.
- Availability is scheduled for mid-2017 to early-2018 (#safeharbor).
With feature enablement , we will be able to use “Dark Launching” to roll-out pilot features to a subset of subscribers before enabling the feature for all subscribers.
Activation Metrics – Plan
- Today, AIPs have access to metrics which help us determine how our packages are being used.
- New activation metrics will be available to AIPs to surface which subscriber is using which features.
With activation metrics, we can guide future planning by observing which features are actually adopted.
NextGen Packaging – Summer ’17 thru Spring ’18
According to various Dreamforce ’16 presentations, a series of build and deploy changes are underway which will make it easier to create richer managed packages with more options in order to better serve specific customer segments.
- End-to-end API coverage
- Operations only available through the user interface will be made available through APIs.
- With end-to-end API coverage, we can script enhance and script release management using popular DevOps techniques
- Source-driven development
- New Force CLI – Node.js open source with plugin support
- New Force.com IDE experience – Uses CLI
- Multiple branches of development
- With source-driven development, we can streamline creation of the last 10% or 20% of bleeding-edge applications.
- App bundles
- Multiple packages per namespace and modules.
- With app bundles, we can segment our solutions and easily install only the bits each subscriber wants or needs.
- Declarative manageability
- Subscriber-controller but upgradeable (e.g. page layouts).
- Obfuscate non-apex components (e.g. flow).
- Avoid breaking changes (e.g. change field data-type).
- Developer-defined rules (e.g. subscriber can modify permsets).
- With declarative manageability, we can balance subscriber customizations with keeping subscribers current.
Given NextGen packaging, both Enterprise developers and App Innovation Partners will find it easier to work together in larger teams and move more features to production sooner.
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. — Wade Wegner, VP of Product for Salesforce DX.
For more see:
- Deep Dive into the New Salesforce Development Experiene (DX) (Salesforce) (new!)
- Adopt a continuous delivery model for your Salesforce apps (Salesforce)
- Salesforce DX (Developerforce)
- Dreamforce ’16 Developer Keynote (@35:30) (Developerforce)
- Salesforce DX = UX for Developers (Developerforce)
- Salesforce.com Introduces Extensive Changes to Developer Experience (InfoQ)
- Salesforce DX: Streamline Development on the Salesforce Platform (Trifecta)
- Salesforce DX Quick Take (Peter Knolle)
- Related – Salesforce Heroku DX (Developerforce)
