The Product Delivery Model is an evolution of the Package Development Model which defines the product as an automated recipe developed in version control to deliver a product experience into an org. While installing a package version is likely a part of that recipe, there is far more automation necessary to deliver a complete product experience.
The product experience recipes are used throughout the product lifecycle from development to test to release to delivery, ensuring a reliable and repeatable process for delivering product experiences instead of just creating a package version artifact. Since the recipes are in version control, all the compliance functionality of your VCS host (i.e. GitHub) applies to the complete delivery process instead of just the package.
Here’s a simple test… If you had to rebuild your Trialforce Source Org (TSO) or your persistent QA org, how long would that take you?
For most ISVs, the answer ranges from 2–4 hours up to days. For some, the mere thought of having to recreate those orgs evokes a feeling of horror.
In the Product Delivery Model, all the manual steps necessary to create a usable environment are tech debt and automating delivery is part of feature development. Say no more to product managers complaining about developers spending time on automation instead of features. Automation is a feature of the product, not something tossed over the wall to another team after development.
Components of a Product Experience Recipe
So what goes into an automated recipe to deliver a product? It’s a combination of Dependencies, a Package, Unpackaged Metadata, Settings and Configuration, and Datasets. An individual recipe may only use a few of those categories, but a complete recipe must consider all of them.
Use Cases for Product Experience Recipes
By building recipes in version control, development teams create portable automation that can be used throughout the product lifecycle. Some use cases made possible by the Product Delivery Model are:
- Developers work in orgs that resemble a customer org rather than waiting until release for their code to be tested in a realistic environment
- Continuous Integration applications can use recipes to spin up test environments
- QA Testers can self-service create scratch orgs to fully test new features before they are merged
- UX Designers can self-service create a scratch org fully configured to evaluate the implementation of a new UX before it’s merged
- Doc writers can self-service create a scratch org fully configured to capture screenshots of a new feature before it is merged
- Demo/Solutions Engineers can start building out demo configurations for a new feature before it’s merged and can create modular demo configurations instead of overloading a demo org with all scenarios for all demos
- Implementation Partners can use automation recipes to build their own recipes for common implementation patterns, driving down implementation costs and improving customer success
- ISV Partners building extension packages can use automation recipes to build their own recipes for their extension packages
- Customers can run recipes against their existing org to install products using MetaDeploy like https://install.salesforce.org
All of these use cases can be solved for with one investment, planned as part of product planning. The alternative is inefficient processes for each use case held together by manual operations.
Tooling for the Product Delivery Model
While the Product Delivery Model is more a concept than a process or architecture, there are some tools that enable and streamline implementing it. Salesforce.org has been using the Product Delivery Model for years to deliver Nonprofit Cloud and Education Cloud to tens of thousands of customer orgs. CumulusCI was built by Salesforce.org for the Product Delivery Model and released as open source so Salesforce’s partners and customers could use it too.
Using CumulusCI, product teams define their product’s recipes in a cumulusci.yml file stored in their GitHub repository. Recipes can be made up of a rich set of built in tasks in CumulusCI, any operations available through sfdx including plugins, and any command line operations. This flexibility makes it possible to automate even the most complex of configurations.
This post is more focused on the Why than the How. Look out for future posts that cover the tooling in more depth.
Scratch Orgs and the Product Delivery Model
Scratch Orgs are a key component to being successful with the Product Delivery Model because they allow you to “start from scratch” with a clean org created from a repeatable org shape definition. This is the perfect environment for testing out product experience recipes.
Consider it a red flag when your users request scratch orgs that last 30 days
It’s quite likely the reason they want longer running scratch orgs is because they had to manually do configuration in their scratch org to make it usable for them and the idea of losing all that manual work is stressful.
The right answer here is that there is a feature gap in the product. Again, the key is to view the product as the recipe to deliver an experience to internal and external constituents.
Conclusion
The Product Delivery Model offers a solution to many of the pain points of ISV-style development on Salesforce. While implementing successfully requires some up front investment, the efficiency and quality gains in the development and release process and the new possibilities in how you deliver to customers makes that investment continue to pay off for years to come.
Interested in exploring how the Product Delivery Model could work for your products? Grab a time to talk at https://calendly.com/muselab
Comments