Quick Reference: Development Lifecycle (D6)

Fast-track refresher for Domain 6, covering environments, CI/CD, testing, governance, and risk management. This domain is where CTAs prove they can deliver, not just design. Read this, then review the DevOps Quick Reference for detailed tables.

What the Board Wants to Hear

Board Question	What They Are Testing	How to Answer
”What is your environment strategy?”	You understand sandbox types and their purpose	Name specific sandbox types per stage: Dev, SIT (Partial), UAT (Partial), Staging (Full)
“How do you handle deployments?”	CI/CD maturity, not change sets	Describe the pipeline: Git branch, PR, scratch org validation, promote through environments
”What is your testing strategy?”	Test pyramid thinking, not just “75% coverage”	State: automated unit tests at base, integration tests in middle, manual UAT at top
”How do you manage risk?”	Proactive risk identification woven into architecture	Name top 3 scenario-specific risks with mitigation strategies
”What governance do you recommend?”	ARB, CAB, CoE awareness	Hybrid CoE with central standards and BU delivery teams

Environment Strategy - One-Page Summary

Sandbox Types

Type	Data	Storage	Refresh	Best For
Developer	None	200 MB	1 day	Individual feature dev
Developer Pro	None	1 GB	1 day	Dev + unit testing
Partial Copy	Sample (template)	5 GB	5 days	SIT, UAT
Full Copy	All production data	Same as prod	29 days	Staging, performance testing
Scratch Org	None (scripted)	Ephemeral	Created per branch	CI/CD validation

Standard Environment Topology

Figure 1. Staging with a Full Copy sandbox is the last gate before production and the only environment where performance testing at production-scale data is possible. Skipping Staging is one of the most common DevOps anti-patterns the board will probe.

Data Masking is Non-Negotiable

Any sandbox copying production data (Partial Copy, Full Copy) MUST mask PII. Use SandboxPostCopy Apex interface for automated post-refresh masking. In regulated industries (HIPAA, GDPR, SOX), failure to mask is a compliance violation. Always mention this at the board.

CI/CD Pipeline - The Complete Picture

Branching Strategy

Modified GitFlow is the standard CTA recommendation for enterprise teams:

main              - Reflects production
  develop         - Integration branch, deployed to SIT
    feature/XYZ   - Short-lived feature work
  release/Q4      - Release candidate, deployed to UAT/Staging
  hotfix/BUG-123  - Emergency production fix

Strategy	Team Size	Release Cadence	CTA Default?
Modified GitFlow	Large (10+)	Scheduled (monthly/quarterly)	Yes - for most enterprise scenarios
Trunk-Based	Small-Medium	Continuous	Only if strong CI/CD + high test coverage

Deployment Mechanisms

Mechanism	When to Use	When to Avoid
Salesforce CLI (sf)	Enterprise, CI/CD, multi-developer	Never avoid - this is the standard
Unlocked Packages	Modular orgs, dependency management	Simple orgs with one team
Change Sets	Tiny team (1-2 admins), simple changes	Multi-developer, complex orgs
DevOps Center	Teams transitioning from change sets	Mature CI/CD teams already using CLI

Board Signal on Change Sets

If the scenario mentions change sets, recommend modernizing to CLI/package-based deployment. Acknowledge the current state, explain the risks (no rollback, no version history, no CI/CD), and propose a phased migration path. Do not propose ripping them out overnight.

Testing Strategy - The Pyramid

Test Types by Environment

Test Type	Where	Automated?	What It Validates
Apex Unit Tests	Scratch Org, Dev	Fully	Individual methods, business logic
LWC Jest Tests	Scratch Org, Dev	Fully	Component rendering, behavior
Static Analysis	CI pipeline	Fully	Code quality (PMD, ESLint)
Integration Tests	SIT (Partial Copy)	Mostly	Cross-object, cross-system
UAT	UAT (Partial Copy)	Manual	Business process validation
Performance Tests	Staging (Full Copy)	Semi	Load, query, API throughput
E2E Tests	SIT/UAT	Semi (Provar, Copado RT)	Full user journeys

The Coverage Rule

What to Say	What NOT to Say
”85%+ coverage with meaningful assertions that validate business outcomes"	"We will achieve 75% coverage"
"Automated regression tests gate every deployment"	"We will test manually before go-live"
"Test data factory pattern with @TestSetup for isolation"	"We will use SeeAllData=true”

Governance - Key Structures

ARB vs CAB

	Architecture Review Board	Change Advisory Board
Focus	Design decisions	Deployment decisions
When	Before building	Before deploying
Question	”Is this the right solution?"	"Is this safe to deploy?”
Participants	Architects, tech leads	Release managers, QA, ops

Architecture Decision Records (ADRs)

Document key decisions using ADRs - see Governance Model Deep Dive for the template and when-to-write guidance.

CoE Model Recommendation

For most CTA scenarios: Hybrid CoE. A central team owns architecture, standards, and shared services. BU teams own delivery within guardrails. This balances governance with delivery speed.

Model	Best For
Centralized	Small/medium orgs, single SF instance
Federated	Large enterprises with independent BUs
Hybrid	Most enterprise scenarios (CTA default)

Risk Management - Top CTA Patterns

The Risk Formula for Board Presentations

“The top risk I see in this scenario is [risk]. It is likely because [scenario-specific reason]. If it materializes, the impact is [consequence]. My architecture mitigates this by [decision]. As a contingency, [fallback plan].”

Common Scenario Risks

Scenario Element	Risk	Mitigation
High data volume	Performance degradation	Skinny tables, custom indexes, Full Copy perf testing
Complex integrations	Integration failure	Circuit breakers, retry logic, dead-letter queues
Multiple user personas	Permission/sharing issues	Profile-specific test scenarios
AppExchange-heavy	Vendor lock-in, governor conflicts	Vendor scorecard, exit strategy, limit budget
Multi-cloud	Data inconsistency	Event-driven sync, conflict resolution rules
Data migration	Data quality issues	Validation scripts, reconciliation, phased migration

Reverse-Engineered Use Cases

Scenario 1: Global Financial Services Firm - Multi-Region Rollout

Situation: Bank rolling out Sales Cloud across 3 regions (US, EU, APAC) with SOX and GDPR compliance requirements. 30 developers across time zones.

What you’d do: Modified GitFlow branching. 20 Developer Sandboxes (or DevHub scratch orgs). Per-region SIT sandboxes (Partial Copy). Single UAT, Full Copy Staging. Unlocked packages organized as: Core, Sales-US, Sales-EU, Sales-APAC, Integration. Feature flags for region-specific rollout. Mandatory post-copy data masking for all non-dev environments.

Key governance: Hybrid CoE with central architecture team setting standards, regional delivery teams executing. ARB reviews all cross-region architectural decisions. CAB reviews all production deployments with mandatory rollback plans.

Scenario 2: Healthcare Company - HIPAA-Compliant Implementation

Situation: Hospital network migrating from legacy system. 5 million patient records. HIPAA requires audit logging and PHI encryption.

What you’d do: Shield Platform Encryption for PHI fields. Event Monitoring for audit trail. Full Copy sandbox for performance testing with 5M records - but ALL sandboxes must mask PHI via SandboxPostCopy script. Batch Apex for migration (phased over weekends). Performance test every SOQL query with production-scale data.

Testing strategy: Apex unit tests with 85%+ coverage. Integration tests with HttpCalloutMock. Dedicated performance test pass on Full Copy. UAT with masked data - HIPAA prohibits real patient data in non-production environments.

Scenario 3: Startup Scaling to Enterprise

Situation: 50-person SaaS company growing from 5 to 25 Salesforce users. Currently using change sets with no source control. One admin, no developers.

What you’d do: Phase 1: Introduce Git (GitHub) + Salesforce CLI. Migrate admin to source-tracked development. Phase 2: Set up CI/CD with GitHub Actions - scratch org validation on every PR. Phase 3: Move from change sets to CLI deployments through environments. Keep the process admin-friendly - the admin is the entire team.

Key trade-off: Do not recommend Unlocked Packages yet - overkill for this team size. Start with source-tracked org development model, mature to packages when the team grows. Present a DevOps maturity roadmap, not a big-bang transformation.

Key Anti-Patterns (Board Red Flags)

Anti-Pattern	Why It Fails
Production data in dev sandboxes without masking	Compliance violation (HIPAA, GDPR, SOX)
No rollback plan for deployments	Stuck if deployment causes issues
Change sets for multi-developer team	No version control, no CI/CD, no audit trail
75% coverage target with SeeAllData=true	Testing org data, not business logic
No ARB/CAB governance	Architectural drift, uncontrolled changes
Single full-time developer as single point of failure	Key person dependency risk
Deploying directly to production from dev	Skips SIT, UAT, staging validation

Deep Dive Links

• Environment Strategy: Full sandbox type analysis
• CI/CD & Deployment: Complete pipeline architecture
• Testing Strategy: Test pyramid and automation tools
• Governance Model: ARB, CAB, CoE, RACI, compliance
• Risk Management: Risk register, scenario risks, mitigation
• Trade-Offs: Agile vs Waterfall, change sets vs CLI, and more
• DevOps Quick Reference: Environments, CI/CD, testing, governance combined

Sources

• Salesforce Architects: Release Management
• Salesforce Architects: Environment Planning
• Salesforce Architects: Governance Framework
• Salesforce Developer Docs: Salesforce DX
• Salesforce Help: Sandbox Types