Salesforce DevOps and Release Management
We set up Salesforce DevOps that fits your team: source control, a clear environment plan, CI/CD with the sf CLI, and DevOps Center (Lifecycle Center).
If changes reach production through change sets, late-night fixes or one person's laptop, releases get slow and risky. GeekMidst sets up Salesforce DevOps and release management remotely from India: source control, environments, automated deployment and a release rhythm your team can keep. Building features is covered by Salesforce development services, and test strategy by testing and QA.
DevOps Center, now Lifecycle Center
Salesforce's naming is inconsistent here. The Winter '27 platform blog says "Lifecycle Center (formerly DevOps Center)", the Platform page says "Agentforce DevOps Center", and Trailhead and Help still say DevOps Center. The Winter '27 blog says Lifecycle Center adds Coding Agent Governance and Deployment, with policy enforcement, approvals and audit logs for agent-generated code, described as GA. A third-party source reports that DevOps Center became a native core app, no longer a managed package, in Spring '26.
Salesforce CLI
The current CLI is sf (v2). Salesforce states that sfdx (v7) "will receive no updates", so scripts and pipelines still calling sfdx should move to sf. Also plan for:
- Weekly stable releases on Wednesdays, plus release candidates and nightlies, so pin the version your pipeline uses.
- Secrets are no longer printed. The
SF_TEMP_SHOW_SECRETSworkaround ends on 28 October 2026; use thesf org auth show-*commands instead. sf api request restandsf api request graphqlnow need Node.js 22 or later.
What's included
| Area | What we cover |
|---|---|
| Source control | Repository structure, branching model and pull request reviews |
| Environments | Sandboxes for development, integration, UAT and hotfixes, plus scratch orgs where they help |
| CI/CD | Pipelines that validate, run Apex tests and deploy with the sf CLI |
| DevOps Center | Setup and team workflow for DevOps Center (Lifecycle Center) |
| Release process | Release calendar, approvals, rollback plans and release notes |
| Seasonal releases | Preview sandbox testing before each Salesforce upgrade |
How we work
- 01
Discovery
We review how changes move today, your environments and what has gone wrong before.
- 02
Design
We agree branching, environments, approvals and the tool chain.
- 03
Build
We set up the repository, pipelines and DevOps Center, and bring your metadata into source control.
- 04
Test
We run trial releases through the pipeline, including a deliberate rollback.
- 05
Launch
We switch the team to the new process with a short playbook.
- 06
Support
We tune the pipeline and help with the next seasonal Salesforce release.
Prerequisites and licences
You need a source control provider, enough sandboxes for your environment plan, and a CI tool if you use pipelines. Sandbox types and numbers depend on your edition and licences. Some newer testing features are not GA: in Winter '27, Flow Test Mode is Beta and Apex integration tests are a Developer Preview.
Who it suits
Teams with more than one person changing the org, regulated teams that need an audit trail of changes, and anyone still relying on sfdx scripts.
Common mistakes
- Treating production as the source of truth.
- Too many long-lived branches.
- Skipping the preview sandbox before a seasonal release.
- Pipelines that deploy without running tests.
Related services
Read deployment strategies: change sets, SFDX and DevOps Center, use the release readiness checklist, and see administration services for day-to-day changes.
Questions we hear
Should we use DevOps Center or a CI/CD pipeline?
Is DevOps Center being replaced?
Do our sfdx scripts still work?
Can you help with Salesforce's seasonal releases?
Sources
Make releases boring again
Tell us how you deploy today, and we will suggest a DevOps setup that fits your team.
