#Salesforce #Salesforce Admin #Salesforce DeveloperWhat is the recommended approach for deploying Salesforce customizations between development, testing, and production environments using sandboxes, change sets, Salesforce CLI, and DevOps Center while maintaining sufficient test coverage and minimizing deployment failures?
1 Antwort
The three tools solve the same problem (moving metadata between orgs) at different levels of maturity, so the practical answer is to pick based on team skills and how much control you need.
1. Change sets (declarative, org-to-org)
- You select components one at a time in the source org, upload to a connected org, then validate and deploy in the target.
- It’s fine for a one-off tweak or an admin-only team.
- Change sets don’t work with the Salesforce CLI or source-driven development in general, so nothing lands in version control. Salesforce isn’t planning further enhancements to them, and DevOps Center is positioned to replace them.
- Common pain points: you rebuild the component list for every hop, there’s no easy rollback, and large change sets are hard to troubleshoot.
2. Salesforce CLI (code-first, source-driven)
- Keep metadata in Git as the source of truth. Develop in scratch orgs or sandboxes, and use sf project retrieve start and sf project deploy start to move changes.
- Validate before deploying (--dry-run) and run specified tests (--test-level RunSpecifiedTests) so deployments stay fast and safe.
- Wire it into CI/CD (GitHub Actions, GitLab CI, Jenkins, Azure DevOps): run tests on pull requests, deploy to the integration sandbox on merge, then promote to UAT and production.
- Use delta deployments (for example the sfdx-git-delta plugin) to deploy only what changed, and use sf org login jwt with a connected app for non-interactive authentication.
- This gives the most control and the best auditability, but it requires developers who are comfortable with Git and the command line.
3. DevOps Center (declarative UI on top of Git)
- It’s a free Salesforce tool that gives a point-and-click pipeline. It’s built on the same foundation as the Salesforce CLI, and each project is tied to a GitHub repository. Refer this: devops-center-for-hybrid-teams
- Work items are the main object for defining and tracking changes through their lifecycle. A work item is promoted from one stage to the next in the pipeline, for example Development, QA, UAT, and Production.
- Instead of rebuilding a component list per hop, you create the list once and the work item carries it through the pipeline.
- Combining work items merges their feature branches into one branch, which helps with conflicts and dependencies. Because it sits on GitHub, you can also use native GitHub capabilities such as GitHub Actions.
- It works for hybrid teams: admins stay in the UI while developers keep using VS Code, the CLI, and pull requests. Deployments can be done from DevOps Center or externally with the CLI plugin’s sf project deploy pipeline command, which was in beta when that was written, so check its current status.
Which one should I use?
- Admin-only team, small and infrequent changes → Change Sets (or move to DevOps Center)
- Mixed admin and developer team, wants Git without everyone learning the CLI → DevOps Center
- Developer-led team needing CI/CD, test gating, scratch orgs, unlocked or managed packages → Salesforce CLI + CI/CD
- Large or regulated enterprise needing approvals, rollback and audit → CLI-based CI/CD, or a commercial DevOps tool.
