Application Lifecycle Management (ALM)
Application Lifecycle Management (ALM) is the practice and tooling that govern how a Salesforce application moves from idea to production and on through operations.
Definition
Application Lifecycle Management (ALM) is the practice and tooling that govern how a Salesforce application moves from idea to production and on through operations. The ALM scope covers requirements capture, design, development in dedicated environments, peer code review, automated testing, source-controlled metadata, environment promotion (dev to UAT to staging to production), release planning, change management, deployment automation, and post-release monitoring. The discipline applies whether the team uses change sets, Salesforce DX, or third-party tools like Copado, Gearset, Flosum, or AutoRABIT. The point is the same: keep the path from change to production predictable, auditable, and reversible.
Salesforce ALM has evolved through three major waves. The first was Change Sets, the original UI-driven deployment tool tied to org-to-org connections. The second was the Ant Migration Tool plus Metadata API, which let teams script deployments but still relied on file-based metadata. The third is Salesforce DX, source-driven development with scratch orgs, Source format, Unlocked Packages, and the Salesforce CLI. Most enterprise orgs in 2026 run on a mix of DX plus a third-party ALM tool that adds visualisation, governance reporting, and CI/CD orchestration on top of the platform primitives.
The components of Salesforce ALM in practice
Environment topology
A mature Salesforce ALM topology includes per-developer scratch orgs (or developer sandboxes), one or more integration sandboxes for combined testing, a UAT sandbox for business validation, a staging sandbox that mirrors production, and production itself. Some teams add a hotfix branch sandbox for emergency fixes. The flow is one direction: changes move forward through the chain after gating at each step.
Source control as the source of truth
Modern ALM treats Git as the source of truth. Developers retrieve metadata from their dev org, commit to a feature branch, and merge to a main branch through pull requests. Deployments fire from CI/CD against the metadata in the branch, not against an org. The shift from org-as-source to Git-as-source is the most important transition any Salesforce team makes; it unlocks code review, history, and automation that org-based workflows cannot match.
Salesforce DX and Source Format
Salesforce DX introduced Source Format, which splits metadata into one file per component (one file per object, one per Apex class). Source Format is more diff-friendly than the legacy mdapi format. The Salesforce CLI converts between the two when needed; production deployments still use mdapi under the hood. The format change is what makes meaningful Git-based code review possible.
Scratch orgs and Unlocked Packages
Scratch orgs are short-lived, source-tracked Salesforce orgs spun up per feature branch. They support automated test runs in clean environments. Unlocked Packages let teams bundle related metadata into versioned, deployable units that can be installed and updated like managed packages but stay under the customer's namespace. Both are advanced ALM patterns that pay off mostly in larger teams.
Continuous Integration and Continuous Deployment
CI pipelines run on every pull request: deploy to a scratch org or sandbox, run the test suite, return pass or fail. CD pipelines automate the promotion through environments after manual approval. GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins, and Azure DevOps are the most common host platforms; Copado, Gearset, and AutoRABIT layer Salesforce-aware UIs on top.
Change tracking and metadata diffs
Tracking what changed between two orgs (or between an org and Git) is a recurring need. Salesforce DX source tracking handles it for scratch orgs and modern sandboxes. Third-party tools surface visual diffs for change sets and Pull Requests, with conflict resolution and merge tooling that the standard Salesforce surface lacks.
Governance and release management
Production deploys typically need formal change-management approval. Mature ALM workflows attach the Git PR, the Jira or ServiceNow ticket, the test results, the security scan, and the deployment plan to a single Change Record before release. Audit trails are queryable from the source-control history alongside the org's deployment history.
ALM tool selection
Native Salesforce DX plus a CI/CD platform (GitHub Actions, etc.) suits small to mid-sized teams. Copado, Gearset, Flosum, and AutoRABIT add Salesforce-specific orchestration, visual change tracking, and admin-friendly UI on top. The right tool depends on team size, regulatory burden, and how much admin-driven (low-code) work flows through the same release machinery.
How to stand up Salesforce ALM for a real team
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.
Trust & references
Cross-checked against the following references.
- Salesforce DX Developer GuideSalesforce Developer Docs
- Application Lifecycle Management OverviewSalesforce Help
Straight from the source - Salesforce's reference material on Application Lifecycle Management (ALM).
- Environment ManagementSalesforce Developer Docs
Hands-on resources to go deeper on Application Lifecycle Management (ALM).
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Application Lifecycle Management (ALM) cover?
Q2. Which of these is NOT typically part of a Salesforce ALM toolkit?
Q3. What are the three pillars of a mature ALM practice?
Discussion
Loading discussion…