10. Recommendations and Roadmap¶
Context and Starting Point¶
This whitepaper is written from the perspective of a consulting organization establishing a unified, repeatable DevSecOps standard across Federal Salesforce delivery projects. The roadmap that follows assumes a greenfield starting point - a new project, a new GitHub organization or repository, and a delivery team that may have varying levels of familiarity with source-driven Salesforce development. It is not a migration guide for organizations with existing pipelines, though teams in that position will find the phasing useful as a gap assessment framework.
The three phases below represent a recommended sequence, not a rigid prescription. Projects vary in team size, client constraints, org complexity, and timeline. A small project with a senior team may compress Phases 1 and 2 into the first two weeks of delivery; a large enterprise engagement with multiple workstreams may run certain Phase 2 and Phase 3 activities in parallel. The sequencing reflects dependency order - the things that must be true before other things can be built on top of them - and teams should use that dependency logic, not the calendar labels, as their guide.
Phase 1 - Foundation¶
The goal of Phase 1 is to establish the non-negotiable structural prerequisites that everything else depends on. A project that skips or shortcuts these foundations will accumulate governance debt that becomes progressively harder to address as the codebase and team grow.
Establish source-driven deployment as the only deployment path. Before any pipeline tooling is configured, the team must agree - and the client must understand - that all changes to the Salesforce org flow through the repository. No change sets, no direct CLI deployments outside the pipeline, no manual org modifications that are not immediately committed back to source. The source-driven deployment ratio metric starts at this moment - any deviation from 100% from day one is a signal that the commitment has not been fully adopted.
Initialize the repository structure and branch topology. Set up the Salesforce DX project structure, define the branch strategy appropriate for the project's environment topology, configure the initial sfdx-project.json, and establish the .gitignore and .forceignore patterns. A dedicated GitHub configuration repository marked as a template in GitHub's repository settings - seeded from the consulting organization's configuration repository - allows the new project to be initialized with all scaffolding files in place from the first commit.
Implement PR convention enforcement. Configure amannn/action-semantic-pull-request or equivalent to enforce Conventional Commits format on PR titles in GitHub. Enable squash merge as the only merge strategy on protected branches. These two controls establish the commit history discipline that the automated changelog and release management infrastructure depends on - and are far easier to enforce from the first PR than to retrofit.
Implement JWT bearer flow authentication. Configure the Connected App in the client's Salesforce org, generate the certificate and private key pair, store the private key as a GitHub Actions secret, and validate that the GitHub Actions runner can authenticate to all required orgs.
Wire the basic PR quality gate chain. Stand up the initial GitHub Actions PR workflow with: Prettier formatting verification (prettier --check), Salesforce Code Analyzer static analysis with severity 1 and 2 as blocking, and sf project deploy start --dry-run against the CI sandbox with RunLocalTests. Configure these as required status checks on the integration branch.
Wire Apex test execution as a PR gate. Add Apex test execution immediately alongside the initial quality gates. Start with RunLocalTests as the test level and instrument test result output as structured PR comments. Evaluate RunRelevantTests if the project is running minimum API 66.0 and the test suite grows large enough that RunLocalTests is materially slowing PR cycle time.
Add LWC Jest testing if the project includes LWC components. Configure @salesforce/sfdx-lwc-jest, add jest.config.js to the repository root, wire Jest execution into the PR workflow with paths: filtering, and configure the jest-junit reporter for structured PR output. Establish the Jest coverage threshold in jest.config.js and enforce it as a hard gate from the start.
Stand up the push quality baseline workflow. The push baseline - covering Prettier verification, Code Analyzer static analysis, and LWC Jest tests on every branch push - provides immediate feedback to developers on feature branches before a PR is opened. It is not meaningfully more complex to implement than the PR workflow, and it provides value by reinforcing the shift-left model from the first commit of the engagement. A sample implementation is provided in Appendix A.1.1. This workflow also calls the Release Please reusable workflow on pushes to main, so the release infrastructure is in place from day one.
Configure branch protection and CODEOWNERS. Apply the tiered branch protection model to the repository. Create the initial CODEOWNERS file mapping governance configuration files to the governance team (@<my-org>/admin-team). Enable required Code Owner review for governance file paths on all protected branches.
Install local developer tooling. Ensure every team member has the Salesforce Code Analyzer VS Code extension installed and configured against the project's code-analyzer.yml. Install the Salesforce Extension Pack. Set up husky, lint-staged, prettier, and a bash script for pre-commit formatting enforcement. Add VS Code extension recommendations to .vscode/extensions.json.
Configure the centralized configuration repository. If the organization has an existing configuration repository - which it should, as a direct output of this whitepaper's recommendations - consuming repositories should be wired to it from day one. If the configuration repository does not yet exist, Phase 1 of the first project is the time to build it.
Phase 2 - Hardening¶
Phase 2 builds depth and breadth on the foundation established in Phase 1. The basic pipeline is running; the goal now is to close the gaps, increase the signal quality, and extend coverage to the full change surface of the project.
Implement the structured Code Analyzer feedback pattern. Move beyond raw scanner output to the two-table PR comment pattern - blocking violations and non-blocking violations presented separately, updated on each push. Upload SARIF output to GitHub Code Scanning.
Stand up the metadata drift detection scheduled workflow. Configure the nightly drift detection workflow against the project's sandbox or production org. Start with the alerting pattern - post a structured drift report as a GitHub issue and Slack notification when drift is detected.
Implement secret scanning. Wire a secret scanning tool into Husky pre-commit hooks and as a CI workflow step, using the same configuration file centralized in the configuration repository. Enable GitHub Advanced Security secret scanning if available on the client's GitHub plan.
Configure Dependabot and Renovate. Add dependabot.yml for both npm and github-actions ecosystems. Configure the organizational Renovate preset. Ensure the shared Prettier configuration npm package, if used, is tracked as a dependency by both tools. Update both Dependabot and Renovate configurations to use conventional commit messages.
Implement the metadata type risk classification. Add the path-based trigger conditions and automated PR labeling logic that routes Tier 1 metadata changes to mandatory senior reviewer assignment and unconditional auto-merge block (Section 6, Appendix B).
Phase 3 - Strategic Governance Buildout¶
Phase 3 represents the transition from a well-instrumented delivery pipeline to a mature, self-improving governance system.
Evaluate and adopt RunRelevantTests. If the project is allowed to use beta features and has not yet adopted RunRelevantTests (introduced in Section 5), evaluate it against the PR cycle time and gate pass rate metrics from Phase 2. Instrument the @IsTest(testFor='...') annotation across Apex tests to improve Salesforce's dependency inference accuracy, and mark critical tests with @IsTest(critical=true).
Implement the full dependency analysis baseline. Establish the scheduled full-org Apex test run and scheduled Apex compilation check workflows (Section 6). If the project's org is large and highly interconnected, evaluate the MetadataComponentDependency (beta) Tooling API advanced pattern. By Phase 3 the team has enough operational context to assess whether the implementation cost is justified. (Only do this if the organization is cleared to use beta features.)
Contribute improvements back to the configuration repository. Patterns that worked well on this project - reusable workflow improvements, new composite actions, refined configuration standards, additions to the metadata risk classification matrix - should be contributed back as PRs to the consulting organization's central configuration repository. This is how the configuration repository matures across projects.
Revisit release cadence as a business decision. With a stable, fully automated pipeline in place, the engineering constraint on deployment frequency has been removed. Work with the client to evaluate whether the existing release cadence reflects a genuine business or product need, or is an artifact of the deployment friction that the pipeline has now eliminated. Story-level or on-demand production deployments become viable options where the business and client approval processes support them.
Evaluate the third-party and AI tooling placeholder. By Phase 3 the team has enough production pipeline data to evaluate whether complementary tools - CodeRabbit, Hubbl, AI-assisted code review platforms - would add material value over the baseline Code Analyzer output.
Establish pipeline metrics reporting. Instrument the metrics from Section 9 - gate pass rates, PR cycle time segmented by outcome, source-driven deployment ratio, drift frequency, security finding trends, test suite health - as a recurring report delivered to the technical lead and client stakeholders.
A Note on Cross-Project Learning¶
For a consulting organization, each project is simultaneously a delivery engagement and a learning opportunity. The configuration repository accumulates best practices across projects; the metrics framework reveals patterns across engagements; the governance standards evolve as the organization encounters new client environments, new regulatory requirements, and new Salesforce platform capabilities.
The architecture described in this whitepaper is a starting point, not a finished artifact. Salesforce Code Analyzer reached GA in April 2025 but continues to evolve: the Salesforce Graph Engine is in Developer Preview, RunRelevantTests is in beta, new engines will be added, and the CLI interface will continue to change. GitHub's Rulesets and Actions platform continues to add capabilities. Teams that treat the pipeline as a product - with its own backlog, its own improvement cycle, and its own metrics - will extract compounding value from the investment over the life of the engagement and across the portfolio of engagements that follow.