Mature ALM is the difference between confident weekly releases and the risky, error-prone deploys most teams used to ship. The investment is one quarter; the payoff is forever.
- Move metadata into Git
Retrieve the org's metadata using Salesforce CLI. Commit to a private repository. From this point on, Git is the source of truth, not the org.
- Adopt Source Format
Convert metadata from mdapi to source format using sf project convert source. Source format makes meaningful Git diffs possible.
- Stand up the environment chain
Create dev, integration, UAT, staging, and production sandboxes (or scratch orgs for dev). Define which environment promotes to which and who can approve each promotion.
- Build a CI pipeline
Configure GitHub Actions (or equivalent) to run on every PR: validate the metadata, run Apex tests, return a status check. Block merges on failed checks.
- Define release management process
Document who approves production deploys, what evidence (test results, security scan, change ticket) is required, and the rollback procedure. Treat releases as routine rather than as events.
- Switching from org-based to Git-based ALM mid-project is hard. The transition is easier at the start of a major release or a green-field project.
- Low-code work (Flows, Page Layouts, Reports) lives in the same metadata as Apex. Both kinds of change need the same source control discipline.
- Production deploys still need 75 percent code coverage. CI pipelines that pass with low coverage fail at the production gate.
- Third-party ALM tools add cost and complexity. Start with native DX plus a basic CI pipeline; layer tools only when the team's needs justify them.