Skip to content

Product Delivery Model with Org Manifests

Jump to bottom
Jannis Schreiber edited this page Oct 29, 2024 · 4 revisions

The Product Delivery Model fundamentally comes down to how you bring updates to your users. Packages are just a technical means to modularise a system. It is a (mostly) technical decision which package implements what functionality or if something is deployed as unpackaged metadata. In the end, users are primarily interested in the total functionality of the entire system.

That's what an Org Manifest does: It configures the modules (packaged or unpackaged) that comprise a system. It works best for teams that think of their packages as a software catalogue, and their target org(s) as a selection of installed software from said catalogue. It is designed for a multi-org architecture, where each subsidiary (or business unit) has their individual needs. Org Hierarchies can be identical, but they typically differ slightly to cater the individual requirements.

Product Delivery Workflow

On a high level, the workflow is simple:

  1. Modules (usually unlocked packages) are developed independently. When a new version is ready, it is promoted (released) similar to how an independent software vendor publishes a new version of their product.
  2. When business is ready, it can decide to rollout a product increment to their Org Hierarchy. The increment can consist of a single package version or comprise multiple package versions with unpackaged metadata.
  3. The increment is defined in the Org Manifest, as the total sum of all changes artifacts.

The org manifest defines the complete state of the org, and the file history explains how this state happened.

Benefits

  • The technical decision of package architecture and release is entirely decoupled from the business decision of a rollout. This allows developers to complete their work (merge pull requests, package promote, run regression tests, etc.) without being dependent on the business decision, if their increment should be rolled out.
  • Business can do UAT on their terms and is not pressured by IT to complete a review (work can still pile up, but dev teams are not blocked, if a department does not have the capacity to review changes immediately).

Clone this wiki locally