DevOps Center Patterns

Overview

This guide captures practical DevOps Center patterns based on real implementation notes and migration experience from manual deployments.

The focus is not “perfect enterprise CI/CD from day one.” The focus is establishing a reliable source-tracked release workflow that teams can actually adopt.

Consensus Best Practices

• Treat DevOps Center as a workflow layer over Git, not as a full ticketing platform.
• Use Developer Sandboxes (not Partial) for source-tracked work.
• Keep pipeline stages simple first (Sandbox -> Production), then expand only when needed.
• Standardize work item hygiene: title, external ticket URL, clear deploy scope.
• Avoid profile deployments where possible; favor permission sets and permission set groups.
• Use branch and repository naming conventions from day one.
• Keep production break-glass changes rare and reverse-merge immediately when they happen.

Recommended Operating Model

1) Project Setup

• Enable Dev Hub and source-tracked sandbox support.
• Connect a company-owned GitHub repository (not personal account).
• Create one DevOps Center project per Salesforce org landscape.

2) Environment Strategy

Start simple:

• Development: source-tracked Developer Sandboxes.
• Production: release target.

Only add integration/UAT/staging stages when the team has repeatable quality gates and clear ownership for each stage.

3) Work Item Lifecycle

1. Create a work item.
2. Link to external ticket in description.
3. Build in source-tracked sandbox.
4. Pull and select metadata intentionally.
5. Commit with meaningful summary.
6. Create review.
7. Mark ready to promote.
8. Promote in planned release window.

Metadata Selection Patterns

• Keep work items small and cohesive.
• Split unrelated components into separate work items.
• Validate that required dependencies are included before promotion.
• Keep human review on sensitive metadata: sharing/security, automation, and integration endpoints.

Common Failure Modes

• Overloading one work item with unrelated changes.
• Treating DevOps Center work items as a full backlog system.
• Ignoring naming conventions across repos and environments.
• Deploying profiles unintentionally.
• Using non-source-tracked sandboxes and expecting reliable pull behavior.

Migration Pattern: Change Sets to DevOps Center

1. Freeze ad-hoc change set usage except emergency fixes.
2. Introduce DevOps Center for one pilot domain.
3. Enforce branch/review standards for pilot team.
4. Measure failure rate, lead time, and rollback frequency.
5. Expand scope after two stable release cycles.

Governance Checklist

• Repository ownership is organizational.
• Work item links map to ticketing system records.
• Promotion requires reviewer sign-off.
• Emergency production changes are documented and back-merged.
• Release notes list promoted work items and metadata scope.

Sources Used

• Knowledge/Jodie Miners/TDD-DevOps-Center.md - Practical setup and operating lessons from DevOps Center adoption

Related Patterns

• Deployment and CI/CD Patterns
• Salesforce DX Patterns
• CI/CD Patterns