Development Lifecycle Decision Guides

These flowcharts cover the most common development lifecycle decisions a CTA faces. They turn ad-hoc choices into a structured process and show architectural rigor to the review board.

Branching Strategy Decision

Use this when choosing between GitFlow, trunk-based development, or a hybrid approach for a Salesforce project.

Figure 1. Most enterprise Salesforce teams with scheduled releases land on Modified GitFlow. Trunk-based development is optimal for small teams with mature CI/CD but carries higher risk when metadata merge conflicts occur.

Branch Strategy Quick Reference

Strategy	Best For	Overhead	Risk
Trunk-Based	Small team, continuous delivery, mature CI/CD	Low	Medium (requires feature flags)
Feature Branch	Small-medium team, regular releases	Low-Medium	Low
Modified GitFlow	Medium team, scheduled releases	Medium	Low
Full GitFlow	Large team, infrequent releases, multiple environments	High	Low
GitFlow + Workstreams	Very large team, independent feature sets	Very High	Low

---

Choosing a CI/CD tool: Start with team maturity. An admin-centric team with no CLI experience should not be handed a GitHub Actions pipeline on day one — DevOps Center or a tool like Gearset provides a GUI transition path. A team with an existing CI/CD platform (GitHub, Azure DevOps, GitLab) should extend it with Salesforce CLI rather than introducing a second toolchain. Package-based development (unlocked packages) pairs naturally with general CI/CD tools since package operations are pure CLI. Compliance-heavy scenarios (financial services, healthcare, government) favor Copado, which has built-in audit trail capabilities and compliance tracking. Wrong answers: recommending Copado for a small admin team because “it’s Salesforce-native,” recommending GitHub Actions for an admin team unfamiliar with Git.

CI/CD Tool Selection Decision

Use this when choosing a CI/CD tool for a Salesforce implementation.

Figure 2. Reusing an existing CI/CD platform (GitHub Actions, Azure Pipelines, GitLab CI) avoids introducing a second toolchain and reuses team familiarity. SF-native tools like Copado add value specifically when compliance audit trails or admin-friendly pipelines are the priority.

---

Choosing an environment strategy: The first question is team size — how many developers are working in parallel, and do they need isolated environments? A team of five needs three to five Developer Sandboxes plus one Partial Copy SIT and one Partial Copy UAT as a minimum. A team of twenty or more needs scratch orgs via DevHub for CI/CD, multiple SIT environments if workstreams are independent, and a Full Copy Staging sandbox. The second question is whether performance testing is in scope: if the scenario mentions large data volumes, a dedicated Full Copy sandbox for performance testing is required, because performance test results from a Partial Copy sandbox cannot predict production behavior. Wrong answers in CTA scenarios: a single sandbox for all purposes, Partial Copy for performance testing, or recommending scratch orgs alone without a persistent integration testing environment.

Sandbox Strategy Decision

Use this when designing the environment topology for a Salesforce implementation.

Figure 3. A dedicated Full Copy sandbox for performance testing is only justified when data volume makes performance a real risk. For most mid-size teams, one Staging Full Copy serves both pre-production validation and load spot-checks.

---

Choosing between packages and change sets: Any scenario with more than a handful of developers, multiple parallel workstreams, or significant deployment automation needs eliminates change sets as a long-term strategy. Change sets have no rollback capability, no automated testing integration, no version history, and no dependency validation. Unlocked packages provide versioned, repeatable, dependency-aware deployments with a clean rollback path (install prior promoted version). The realistic answer for enterprise scenarios is a migration path: acknowledge the current change set reality, propose Salesforce CLI as the first step, then unlocked packages as the organization’s DevOps maturity increases. Wrong answers: recommending change sets for multi-team implementations, recommending unlocked packages without addressing the team’s readiness for package architecture.

Change Sets vs CLI Decision

Use this when evaluating whether an org should continue using change sets or migrate to CLI-based deployment.

Figure 4. The presence of any developer on the team immediately disqualifies change sets as a long-term strategy. CLI-based deployment is the only path to merge workflow, automation, and audit history. GUI tools like Gearset bridge the gap for teams not yet ready for full CLI adoption.

---

Designing a testing strategy: The test pyramid is non-negotiable. Apex unit tests form the base — 85%+ coverage with meaningful assertions, not coverage padding. LWC Jest tests sit alongside Apex at the unit level. Mock callout tests handle integration testing within the CI/CD pipeline. Automated E2E tests using Provar or Copado Robotic Testing gate UAT readiness. Manual exploratory testing and formal UAT sign-off sit at the top of the pyramid. Performance testing is separate: it requires a Full Copy sandbox with production-scale data, and the scenario’s risk profile determines how much to invest. Wrong answers: “we will achieve 75% coverage,” proposing E2E automation without unit tests at the base, claiming performance testing in a Partial Copy sandbox.

Testing Approach Decision

Use this when determining the testing strategy for a Salesforce implementation.

Figure 5. Performance testing without production-scale data produces meaningless results. Only a Full Copy sandbox reveals how SOQL queries and batch jobs behave under real data volumes. All other test types can run on lower-fidelity environments.

---

Governance Structure Decision

Use this when determining the right governance model for a Salesforce implementation.

Figure 6. Multi-org enterprises need a Federated CoE where each org maintains its own CAB but a cross-org ARB ensures architectural consistency. Without that cross-org layer, standards diverge and integration complexity multiplies with each new org.

Deployment Rollback Decision

The review board often asks: “What is your rollback plan?” This decision tree maps the right approach based on severity, deployment method, and whether destructive changes were involved.

Figure 7. Unlocked packages provide the cleanest rollback path: installing the previous promoted version is a single CLI command. Destructive changes in CLI deployments or any change set deployment require manual recovery, reinforcing why destructive changes need explicit CAB sign-off before every release.

Destructive Changes Block Rollback

Destructive changes (deleted fields, objects, classes) are the biggest rollback risk. Once metadata is deleted in production, restoring it requires manual recreation. There is no automated undo. Every deployment plan must document destructive changes separately, and they require explicit CAB approval.

---

How to Use These Guides in a CTA Scenario

1. Identify the lifecycle decisions required by the scenario. Not all will be relevant.
2. Walk through each relevant flowchart using the scenario’s specific constraints
3. Document the path and the answers to each decision question
4. Present the decisions as part of governance and DevOps architecture
5. Connect decisions to risk mitigation. Many lifecycle choices directly reduce project risk.

Review Board Strategy

At the CTA Review Board, governance and DevOps are often combined into a single artifact section. Show the environment topology diagram, CI/CD pipeline, and governance structure together to present a cohesive lifecycle strategy.

Related Topics

• Environment Strategy: Detailed environment design
• CI/CD & Deployment: Full CI/CD pipeline architecture
• Testing Strategy: Full testing approach
• Governance Model: Governance structures in depth
• Risk Management: How lifecycle decisions mitigate risk
• Best Practices: DevOps best practices and anti-patterns

Sources

• Salesforce Architects: Release Management Decision Guide
• Salesforce Architects: Environment Planning
• Atlassian: Comparing Git Workflows
• Martin Fowler: Continuous Integration
• CTA Study Groups: Community patterns for lifecycle decision frameworks