Quick Reference: Development Lifecycle (D6)
Fast-track refresher for Domain 6. Covers 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
flowchart LR
DEV["Dev Sandboxes\n+ Scratch Orgs"] --> SIT["SIT\n(Partial Copy)"]
SIT --> UAT["UAT\n(Partial Copy)"]
UAT --> STAGE["Staging\n(Full Copy)"]
STAGE --> PROD["Production"]
style DEV fill:#2d6a4f,stroke:#1b4332,color:#fff
style SIT fill:#4ecdc4,stroke:#3ab5ad,color:#000
style UAT fill:#4ecdc4,stroke:#3ab5ad,color:#000
style STAGE fill:#f4a261,stroke:#d4823e,color:#000
style PROD fill:#e76f51,stroke:#c45a3f,color:#fff
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 default 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 — 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