Development Lifecycle, Deployment, and Governance
Development Lifecycle, Deployment, and Governance
This domain tests environment strategy, source-driven delivery, release governance, and whether you can keep forty developers from colliding in one org.
Environments and ALM
Scratch orgs for feature development; Developer and Developer Pro sandboxes for integration work; Partial Copy sandboxes with a data template for UAT; Full Copy for performance and release rehearsal. Source control - not the org - is the source of truth. Salesforce DX with source tracking replaces change sets for teams of any size.
Packaging
Unlocked second-generation packages for internal modularity, so domains such as sales, service, and shared components deploy independently. Managed second-generation packages for ISV distribution. Org-dependent unlocked packages when metadata depends on org-specific features. Package boundaries enforce architecture; they are a governance mechanism as much as a delivery one.
Pipeline and governance
Validate on pull request, run Apex tests, apply static analysis (Salesforce Code Analyzer or PMD rules), scan for security issues, deploy to staging, then promote the same artifact. Maintain a release calendar, a branching convention (trunk-based with short-lived branches or Gitflow), and a documented hotfix path. Keep a technical debt register and a deprecation plan. Test data must be seeded, not copied from production, unless you have a compliant masking process.
Worked example
Forty developers, one org, weekly releases, change sets failing weekly because of missing dependencies. Move to Salesforce DX with source tracking and four unlocked packages: shared, sales, service, and integrations. Each package deploys independently; shared is a dependency of the rest. The pipeline validates every pull request against a scratch org and deploys to UAT on merge. The reasoning: package boundaries reduce deployment conflicts and force explicit dependency management - but only after a metadata coverage check confirms nothing critical is excluded.
Traps that cost marks
Treating 75% Apex coverage as a quality gate. Deploying profiles instead of permission sets. Hardcoded record type or org IDs. Undocumented manual post-deployment steps. No rollback plan. Skipping validation against production-like data volumes.
Key points
- Source control, not the org, is the source of truth.
- Unlocked 2GP packages create modularity and reduce deployment conflicts.
- Validate every change in a pipeline before promotion.
- 75% coverage is a platform minimum, not an engineering standard.
- Document rollback and manual steps, or the release is not repeatable.