What does it take to create fully usable experiences of your AppExchange product? Odds are it's a lot more than just installing a package version. While the Package Development Model provides a good process for developing and releasing package versions, it only solves for a small piece of the overall product experienced by your customers.
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
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 both built-in tasks and flows from CumulusCI and custom tasks and flows you create to meet your product's unique needs.
Want to learn more about the Product Delivery Model and how CumulusCI can help your team? Book a free consultation to discuss your challenges and how we can help.