Environment strategy
A sandbox, scratch org and UAT map matched to the real working cadence.
Salesforce CI/CD & DevOps
Releases stop being stressful events once they have a process.
We build a governed release pipeline for Salesforce: a single source of truth in Git, defined environments, automated testing, quality gates and a rollback path — so every change reaches production predictably and on the record.
Release pipeline
How a change travels from development to production
The diagram shows the full pipeline, from the environment where the change is written to the controls that follow go-live.
Governed Release Pipeline
Source
Where the change starts
- Scratch org / sandboxIsolated development
- Metadata in GitSingle source of truth
- Branch per work itemTraceable to a requirement
Integration
What runs automatically
- Pull requestReview required
- Static analysisPMD and code standards
- Apex testsCoverage and quality
Quality gates
What blocks promotion
- Minimum coverageThreshold agreed upfront
- Regression suiteCritical scenarios
- Business sign-offDocumented UAT
Release
How production is reached
- Automated deploySame artifact promoted
- Data seedingConsistent environments
- Release windowScheduled and announced
Control
What happens afterwards
- Planned rollbackKnown way back
- Monitoring and alertsDefined thresholds
- Release notesDocumented per version
Background
What actually determines the outcome
In most organizations release incidents aren't caused by bad code — they're caused by the absence of a process. Changes are made directly in an environment, nobody knows exactly what was pushed, and there is no orderly way back.
CI/CD for Salesforce isn't just tooling. It's an agreement about what counts as an approved change, who approves it, which checks must pass, and what happens when something fails.
The right outcome isn't more automation for its own sake. It's a higher release cadence with fewer surprises — and every version explainable, reproducible and reversible.
Areas of work
What we actually do
Metadata in Git
Repository structure, branching and a merge policy the team can sustain.
Automated pipeline
Build, test and deploy through GitHub Actions, Azure DevOps or Gearset.
Quality gates
Test coverage, static analysis and business sign-off as promotion conditions.
Environment data
Consistent test data sets without copying sensitive production records.
Release and rollback
Release windows, release notes and a rollback path defined in advance.
Maturity model
Where the organization stands today
Most organizations sit between level 1 and level 3. The single biggest jump is moving to Git as the source of truth.
| Level | What it looks like | Main risk | Next step |
|---|---|---|---|
| 1 — Manual | Change sets and edits made directly in production | No record and no way back | Move metadata into Git |
| 2 — Partly governed | Git exists but deployment is manual | Drift between environments | Automate the deployment |
| 3 — Automated | A pipeline runs on every pull request | Weak tests that approve everything | Define real quality gates |
| 4 — Governed | Quality gates block promotion | Releases delayed by a heavy process | Focus the regression suite |
| 5 — Continuous | Frequent releases with a known rollback | Operational complacency | Monitoring and periodic reviews |
1 — Manual
- What it looks like
- Change sets and edits made directly in production
- Main risk
- No record and no way back
- Next step
- Move metadata into Git
2 — Partly governed
- What it looks like
- Git exists but deployment is manual
- Main risk
- Drift between environments
- Next step
- Automate the deployment
3 — Automated
- What it looks like
- A pipeline runs on every pull request
- Main risk
- Weak tests that approve everything
- Next step
- Define real quality gates
4 — Governed
- What it looks like
- Quality gates block promotion
- Main risk
- Releases delayed by a heavy process
- Next step
- Focus the regression suite
5 — Continuous
- What it looks like
- Frequent releases with a known rollback
- Main risk
- Operational complacency
- Next step
- Monitoring and periodic reviews
How we work
Delivery steps
- 01
Map the current state
Environments, tooling, release cadence and the real failure points.
- 02
Design the pipeline
Branching, environments and quality gates suited to the team.
- 03
Stand up the infrastructure
Repository, automation and first checks in a test environment.
- 04
Run in parallel
The new pipeline runs alongside the current process until stable.
- 05
Transition the team
Procedures, permissions and role-based training.
- 06
Ongoing control
Measure cadence, failure rate and recovery time.
Continue from here
Related services and guides
FAQ
Common questions
Do we need a large development team to justify CI/CD?
No. Even a team of two or three benefits, because the core value is certainty and traceability rather than scale. A small team simply gets a simpler pipeline.
We mostly work with Flow and configuration. Is this relevant?
Very much so. Configuration and automation changes are metadata like any other, and they are in fact a frequent cause of release incidents. Managing them in Git gives full visibility.
Which tooling do you use?
The choice follows the organization. GitHub Actions or Azure DevOps suit technical teams, while tools like Gearset or Copado fit better when most of the work is configuration.
How long does it take to set this up?
A basic pipeline goes live within a few weeks. Extending it to full quality gates and regression coverage happens gradually, so ongoing development is never blocked.
Next step
Build a release process
We'll map how your environments and releases work today and define the pipeline that fits your cadence.
Next step
Build a release process
We'll map how your environments and releases work today and define the pipeline that fits your cadence.