There are two fundamental approaches to the org-based development model: with source control and without source control. Let's take a look at each.
An example of development environments and release pipelines with org-based development without source control.
In this version of org-based development, changes are tracked and promoted on per-org basis without source control. The top row of the figure above shows release management using Change Sets, built with point-and-click tools via the Setup menu. A unique change set is created in each org in the release pipeline. In the lower stages of the pipeline, unique change sets come from several individual Developer sandboxes into a unified build environment, like a Developer Pro sandbox. Aggregated change sets are then created and deployed to further environments, at each step.
The bottom row shows the development process for development team members who use the Salesforce CLI and can promote changes programmatically. Using
force:source:retrieve commands, a developer can create programmatic change sets in their local development environment, and promote them to the shared Build sandbox. From there, aggregated change sets can be created programmatically in a local development environment through
force:source:retrieve, and programmatically deployed from the local development environment to the next org using
In this approach, conflicts have to be manually resolved in each environment, after all changes have been deployed. Conflicting changes can cause deployments to fail or overwrite prior deployments. Potential conflicts must be tracked to avoid these impacts. This can make fast-paced releases or complex work spread out among different development teams very difficult to manage. This approach is also very limited in visibility and auditability into the release manifest.
This approach is often the most straightforward for teams with little to no experience with programmatic DevOps tooling, but it comes with added governance risks as releases scale and gain complexity. Incorporating source control makes the org-based development model more scalable.
An example of development environments and release pipelines with org-based development with source control. This example also shows a CI/CD integration.
In this version of org-based development, changes are tracked on a per-org basis, relative to the source control system. With this approach, source control is the ultimate source of truth for changes under active development. Development teams check changes into source from their individual developer sandboxes. Conflict management and merging of these changes happens within source control. Aggregated changes are deployed programmatically to build/test/release environments, based on the aggregated changes in source.
Change Sets, created with point-and-click tools through the Setup menu in Salesforce, can still be used on an as-needed basis, as the top line of the graphic above shows.
The usage of source control helps deal with the challenges of merging fast-moving and potentially conflicting changes from lower sandbox environments, and also supports integrating continuous integration and delivery (CI/CD) tools to keep environments in sync. Additionally, this model provides more visibility and auditability into the release manifest.
A key part of this model: source control isn’t suited to holding a long-term release artifact that can be safely and repeatedly deployed in its entirety across releases. This model assumes that with every new release, you refresh source back to a clean slate.
If you need a long-lived artifact with high deployment stability, you should look at package development.
Check out the Architect's Guide to Migrating Changes to learn more about package development.