Note: This resource discusses package development for Unlocked Packages. For guidance with Managed Packages, see the Managed Package Developer Guide.
An example of development environments and release pipelines with package development model.
In the package development model, source control is built to hold long-term artifacts, like all the metadata and configuration information contained in a package and the versions of any packages that are in development. Changes are tracked in source control, relative to a package version. This model also assumes that packages are organized into modular, loosely coupled units of metadata, rather than containing large, monolithic chunks of an org.
In lower environments, development teams iterate through changes relative to a package and develop in scratch org environments, rather than Developer sandboxes. They use
force:source:pull to synchronize changes made declaratively and programmatically in their scratch orgs with the metadata and package information in source. When changes need to be promoted to build/test/release environments, a package and package version are created from the metadata in source. An updated package version is installed to synchronize higher environments.
Note: Package version commands are subject to limits. Depending on your development and release cadence, you may need to adjust at what point in the development cycle you create package versions.
Point-and-click change sets are still available, for promoting changes not contained in a package version or tracked in source. However, if changes deployed by change set (or created manually) are not also synced back to source and into the metadata used to generate the latest package version, the next package installation will overwrite any configuration in the installing org.
Check out the Architect's Guide to Migrating Changes to learn more about package development.