DevOps Best Practices

These patterns reflect what a CTA is expected to know: not just the tools, but how to apply them effectively in enterprise Salesforce organizations.

Best Practices

1. Source Control Everything

Every piece of metadata belongs in source control. Not just Apex and LWC, but Flows, custom objects, permission sets, and configuration. If it is not in source control, it does not exist from a release management perspective.

What to track:

• All Apex classes and triggers
• All LWC and Aura components
• Flows and Flow versions
• Custom objects and fields
• Permission sets and profiles
• Page layouts and record types
• Named credentials and custom metadata
• Validation rules and duplicate rules

2. Automate the Pipeline

Manual deployment is the single biggest source of release errors. Automate every step possible:

• Automated testing on every pull request
• Automated deployment to integration environments
• Automated validation before production deployment
• Automated notifications for deployment status

Figure 1. Every commit triggers automated Apex tests and staging validation before production deployment. Post-deploy monitoring closes the feedback loop and catches regressions that slip through automated checks.

The CTA Standard

In a CTA scenario, always recommend CI/CD automation. Even if the customer currently uses change sets, propose a modernization path. The review board expects guidance toward best practices, not validation of the current state.

3. Validate Before Deploying

Always run a check-only (validation) deployment before the actual deployment:

• Catches missing dependencies before they block the real deployment
• Runs all tests in the target environment, revealing org-specific failures
• Can run during business hours without affecting users
• Builds team confidence before the deployment window

4. Maintain Environment Parity

Keep sandbox environments as close to production as possible:

• Refresh sandboxes on a regular cadence
• Run post-copy scripts to set up environment-specific configuration
• Monitor sandbox drift (metadata differences from production)
• Use tools like Gearset to compare environments and identify drift

5. Use Feature Flags for Safe Deployment

Deploy code to production behind feature flags, then activate features separately from deployment:

• Reduces deployment risk because code is deployed but inactive
• Enables gradual rollout to user groups
• Provides a kill switch for problematic features
• Decouples deployment from release: deploy weekly, release monthly

6. Document Architecture Decisions

Record every significant decision in an ADR (Architecture Decision Record). Future teams need to understand not just what was built, but why.

7. Plan for Rollback

Every production deployment needs a rollback plan:

• Unlocked packages: Install previous version
• Metadata deployment: Deploy previous source version (forward-fix preferred)
• Data changes: Backup data before migration, have restore scripts ready
• Configuration changes: Document pre-change state for manual rollback

8. Separate Metadata Deployment from Data Changes

Deploy metadata and data changes separately:

• Metadata first (objects, fields, automation)
• Data second (records, record type assignments, permission assignments)

This separation allows independent rollback of each layer.

9. Test in Production-Like Environments

UAT and staging should mirror production as closely as possible:

• Full Copy sandbox for staging (if budget allows)
• Production-scale data for performance testing
• Production-equivalent user profiles and permissions
• Production-equivalent integration endpoints (test environments of external systems)

10. Monitor After Deployment

A successful deployment is not the end. Monitor the production environment for:

• Error rates in Apex exception logs
• Page load performance changes
• Integration success/failure rates
• User-reported issues in the first 24-48 hours

Anti-Patterns

Anti-Pattern: The Wild West Org

What it looks like: No source control. Developers and admins make changes directly in production. No deployment process, no testing.

Why it is bad: No audit trail, no rollback capability, no way to know what changed. Changes conflict with each other. Production outages from untested modifications.

Fix: Start with source control. Then sandbox development, then CI/CD. Do not try to implement everything at once; phase the adoption.

Anti-Pattern: Change Set Theater

What it looks like: Change sets handle all deployments, but the process is manual. Components are selected by memory, tests are skipped “because they passed in the sandbox,” and there is no record of what was deployed.

Why it is bad: Human error in component selection. No rollback, no deployment history, no automated testing. Components get missed regularly.

Fix: Migrate to Salesforce CLI + source control. If change sets must stay short-term, at minimum document every deployment and run tests every time.

Anti-Pattern: The Single Sandbox

What it looks like: One sandbox serves all development, testing, and UAT. Multiple developers work in it simultaneously.

Why it is bad: Developers overwrite each other’s work. UAT gets contaminated by in-progress development. No clean testing environment. Deployment conflicts pile up.

Fix: At minimum, separate development from testing. Use developer sandboxes or scratch orgs for development, reserve a Partial Copy for UAT, and add a staging environment for pre-production validation.

Figure 2. Separating development from testing from UAT prevents in-progress work from contaminating acceptance testing. Each promotion gate reduces the risk carried into the next environment.

Anti-Pattern: Tests as Coverage Padding

What it looks like: Test classes create data and call methods but never assert anything meaningful. Tests exist solely to reach the 75% coverage threshold.

Why it is bad: Tests do not catch bugs. Code passes all tests but fails in production. The coverage number is meaningless.

Fix: Require meaningful assertions in every test method. Review test quality during code review, not just coverage percentage. Set a team standard of 85%+ coverage with business-logic assertions.

Anti-Pattern: Big Bang Deployment

What it looks like: Months of development are deployed to production all at once. No phased rollout, no feature flags. All or nothing.

Why it is bad: High risk of failure. If anything goes wrong, everything must be rolled back. Debugging is difficult when many changes land at once, and users are overwhelmed by everything changing simultaneously.

Fix: Deploy frequently in small increments. Use feature flags to deploy code without activating features. Phase rollouts by user group or feature area.

Anti-Pattern: No Rollback Plan

What it looks like: A production deployment proceeds without a documented plan for what to do if things go wrong. The implicit plan is “we’ll figure it out.”

Why it is bad: When a deployment fails at 10 PM on a Thursday, “figure it out” means panic, ad-hoc changes, and making things worse.

Fix: Document the rollback plan before every deployment: what to revert, how to revert it, who does it, and what the communication plan is.

Anti-Pattern: Ignoring Sandbox Drift

What it looks like: Sandboxes are refreshed rarely. Over time, the sandbox metadata diverges significantly from production. Deployments that work in the sandbox fail in production.

Why it is bad: Tests pass in a sandbox that no longer reflects production. Deployments fail because of missing dependencies that exist in production but not in the stale sandbox.

Fix: Refresh sandboxes on a regular cadence. Use environment comparison tools (Gearset, Copado) to detect and resolve drift before it causes deployment failures.

Checklist: DevOps Maturity Assessment

Use this to evaluate the current state and propose improvements in a CTA scenario:

Practice	Level 1 (Basic)	Level 2 (Standard)	Level 3 (Advanced)
Source Control	None	Apex/LWC only	All metadata
Deployment	Change sets	CLI manual	CI/CD automated
Testing	Manual only	Apex tests in pipeline	Full pyramid automated
Environments	1 sandbox	Dev + UAT	Dev + SIT + UAT + Staging
Monitoring	Reactive	Error logs reviewed	Proactive dashboards
Rollback	None planned	Manual documented	Automated package rollback
Governance	None	Informal reviews	ARB + CAB + ADRs

Related Topics

• CI/CD & Deployment: CI/CD pipeline architecture and tools
• Environment Strategy: Environment topology and management
• Testing Strategy: Thorough testing approach
• Governance Model: Governance structures
• Risk Management: Risk mitigation through DevOps practices
• Decision Guides: Decision flowcharts for lifecycle choices

Sources

• Salesforce Architects: Release Management Best Practices
• Salesforce Developer Documentation: Salesforce DX
• Gene Kim, et al: The DevOps Handbook
• Martin Fowler: Continuous Delivery
• CTA Study Groups: Community-sourced anti-patterns from CTA exam preparation