Development Lifecycle & Deployment

Key Takeaways

Development Lifecycle covers environment strategy, CI/CD pipelines, testing, governance, and risk management. Know sandbox types and scratch orgs, when to choose change sets vs unlocked packages vs CLI deployments, and how to design a test pyramid with clear UAT criteria. Governance (ARB, CAB, RACI) and risk mitigation come up often at the review board.

This domain spans project management, testing strategies, governance, environment management, and release management.

Objectives

• Project risk identification and mitigation strategies
• Technical considerations given customer project environment and development methodology
• Recommend a thorough test strategy
• Governance considerations, stakeholders, and impact of decisions
• Platform tools for environment management
• Source control and continuous integration for release management

Study Content

Core Topics

• Environment Strategy: Sandbox types, scratch orgs, DevHub, refresh planning, data masking, post-copy scripts
• CI/CD & Deployment: Git branching, Salesforce DX CLI, change sets, unlocked packages, CI/CD tools, deployment strategies, feature flags
• Testing Strategy: Test pyramid, Apex unit testing, integration testing, UAT planning, performance testing, automation tools
• Governance Model: ARB, CAB, RACI matrix, Salesforce CoE model, ADRs, compliance (GDPR, HIPAA, SOX), data governance
• Risk Management: Risk categories, probability x impact matrix, risk register, common CTA scenario risks, mitigation strategies

Decision Guides & Analysis

• Decision Guides: Mermaid decision flowcharts for branching strategy, CI/CD tool selection, sandbox strategy, testing approach
• Best Practices: DevOps best practices, anti-patterns, and maturity assessment
• Trade-offs: Agile vs waterfall, change sets vs CLI, full vs partial sandbox, manual vs automated testing, centralized vs federated CoE, release cycle length

Practice

• Domain Grilling: D6 Development Lifecycle Q&A

Key Exam Focus Areas

The CTA review board probes Domain 6 with targeted questions. These are the areas most likely to come up and where weak answers cost points:

• Governance structure — The board expects a named governance model (Centralized, Federated, or Hybrid CoE), not just “we will have a governance process.” Identify which model fits the scenario and explain why. Include ARB and CAB as distinct bodies with distinct purposes: ARB governs design decisions before building, CAB governs deployment decisions before deploying.
• When to mandate CI/CD tooling — The board asks “why this tool?” Articulate the decision criteria: team maturity, existing platform investments, compliance audit trail requirements, metadata dependency complexity, and whether the team is admin-centric or developer-led. DevOps Center is not a substitute for full CI/CD in complex implementations.
• Sandbox strategy decisions — Justify every environment in the topology. Explain why performance testing requires a Full Copy sandbox (Partial Copy produces misleading results at scale), why SIT is separate from UAT (business users need a stable build, not one receiving in-flight changes), and why scratch orgs serve CI/CD better than shared sandboxes.
• Unlocked Packages vs Change Sets — The board expects enterprise-scale scenarios to use package-based development. Change sets are acceptable only for admin-only orgs with simple, infrequent releases. When developers are involved, the answer is Salesforce CLI and unlocked packages. Acknowledge a migration path if the scenario describes a team currently using change sets.
• Testing strategy for complex orgs — Present the full test pyramid, not just “we will write Apex tests.” Map each test type to its required environment, state the coverage target (85%+ with meaningful assertions), and address performance testing explicitly if the scenario mentions high data volumes or concurrent users.
• Release train patterns — Scenarios with multi-team or multi-cloud complexity expose release coordination risk. Recommend release trains with freeze periods, feature flags to decouple deployment from release, and a documented hotfix process that uses emergency CAB approval but still requires post-implementation review.
• Risk identification and mitigation — Domain 6 candidates score higher when they surface risks proactively rather than waiting for the board to ask. Identify the top three to five scenario-specific risks, rate each by probability and impact, explain what the architecture does to prevent each, and describe the contingency if prevention fails. Connect risk decisions back to architectural choices (“I chose middleware over point-to-point integration partly to reduce integration failure risk”).
• Compliance and regulatory constraints — If the scenario mentions healthcare, financial services, or government, address compliance frameworks directly. Name the applicable regulations (HIPAA, SOX, PCI-DSS, GDPR, FedRAMP), state the Salesforce products that satisfy them (Shield Platform Encryption, Event Monitoring, Field Audit Trail, Health Cloud BAA), and frame compliance requirements as architectural constraints that take precedence over technical preferences.

Related Topics

Development lifecycle decisions depend on what is being built and delivered:

• Solution Architecture — the chosen solution approach (declarative vs programmatic) determines deployment complexity; Apex triggers and complex Flows require more pipeline rigor than configuration-only changes. AppExchange package decisions go through ARB. Technical debt tracking is a governance responsibility.
• Integration Architecture — integration deployments add complexity: Connected App configs, Named Credentials, API versioning, and external system test environment coordination all belong in the deployment checklist. Integration testing (mock callouts in unit tests, live endpoints in SIT) requires environment planning.
• Communication & Presentation — release planning artifacts, stakeholder change communication, and post-deployment status reporting are lifecycle deliverables. How risks are communicated to the steering committee, the CAB, and end users is a governance and communication responsibility.

Frequently Asked Questions

What development lifecycle topics does the CTA exam test?

The CTA exam covers environment strategy (sandbox types, scratch orgs, DevHub), CI/CD pipelines (Salesforce DX CLI, unlocked packages, deployment strategies), testing strategy (test pyramid, Apex testing, UAT, performance testing), governance models (ARB, CAB, RACI, CoE), and risk management (risk registers, probability x impact matrices, mitigation strategies). Expect questions that test both tool knowledge and judgment about when each approach fits.

How is Development Lifecycle scored in the CTA review board?

Judges look at whether the environment strategy matches project complexity, whether the CI/CD approach is realistic for the team and timeline, and whether testing covers all levels of the pyramid. They also evaluate governance structures relative to the organization size, and whether you identified and addressed key project risks with concrete mitigation plans.

What are the most common mistakes in Development Lifecycle during the CTA exam?

Common failures: proposing an overly complex CI/CD pipeline for a small team, skipping data migration testing with trial loads, ignoring governance for multi-team environments, defaulting to change sets when the scenario clearly warrants source-driven development, and missing risk factors that the scenario paper explicitly calls out.

How should I choose between change sets, Salesforce CLI, and unlocked packages?

Change sets suit small organizations with simple, infrequent deployments. Salesforce CLI (source tracking, scratch orgs) fits teams practicing source-driven development with version control. Unlocked packages are the right choice when modular, versioned deployments with dependency management span multiple teams. Let team size, release frequency, and organizational complexity drive the decision.

What governance structures should I include in my CTA solution?

At minimum, address an Architecture Review Board (ARB) for design decisions, a Change Advisory Board (CAB) for production deployments, a RACI matrix for key project roles, and a Center of Excellence (CoE) model for ongoing Salesforce governance. Scale formality to the organization. A 50-person company needs lighter governance than a 10,000-person enterprise.