Development teams building on the Salesforce platform face the significant challenge of delivering at pace for the business, while managing parallel work streams for admins and developers. In the wider world of software engineering, this challenge has been solved with DevOps, and so increasingly DevOps is also seen as the go-to solution for Salesforce development.
In this post we’ll explore the five pillars of Salesforce DevOps success, to guide your next steps on the adoption journey.
Why have a Salesforce DevOps strategy?
While your Salesforce team may have begun adopting DevOps practices and principles already, you’ll need a coherent approach to guarantee the benefits of DevOps. That’s where DevOps strategy comes in, helping to keep everyone on the same page when it comes to your objectives, measures of success, and strategic direction.
Your team or business will know what it wants Salesforce to deliver. In support of those goals, it pays to have a strategy for how that work is delivered.
How to create a DevOps strategy
The starting point for defining a strategy has to be an honest analysis of your existing setup. What are your strengths and weaknesses? What are the pain points, blockers, and points of friction? A good place to start is our DevOps Assessment — a quick quiz that will automatically generate a tailored report about your DevOps maturity and performance.
Next, you should identify your objectives. What will adopting DevOps help you to achieve? How will you explain the ROI of DevOps to the wider business? It’s true that DevOps makes developers’ lives easier, but the bigger picture also needs to be in scope. Ultimately, it’s about making Salesforce really deliver for the business.
You’ll also need to agree on measures of success, and what benchmarks you’re aiming for. The most commonly used KPIs for DevOps performance are the DORA metrics: deployment frequency, lead time for changes, change failure rate, and time to recover. You can see what makes an elite team in our annual State of Salesforce DevOps report.
Discuss the current state of play and future goals as a team and with relevant stakeholders. That way, everyone develops a shared view of the present and vision for the future. Buy-in is vital for any DevOps transformation, as DevOps is first and foremost a way of working — not a set of tools.
Implementing a DevOps strategy
A “big bang” DevOps implementation hardly ever works. Instead, you should take a step-by-step approach, building on each success and constantly iterating for continuous improvement.
To get an idea of what each of these steps or “stages of maturity” can look like, check out this explanation of DevOps maturity. Obviously all teams are different and there’s no linear path to follow to become fully mature. But there are some essential areas that elite DevOps teams master, and are a good guide when designing a DevOps strategy.
The pillars of Salesforce DevOps success
1. Reliable deployments
Whether you’re deploying org to org or have begun using version control, you need to build your DevOps strategy from the ground up, and deployments are the foundation. If your deployments are a bottleneck, you won’t be able to adopt more complex DevOps processes like version control or CI/CD — particularly as your orgs grow in size and complexity.
Deployments shouldn’t be a time sink. You shouldn’t need to do manual tracking of changes. You should have confidence that deployments will work, and that any issues will be flagged or easily rolled back.
If that doesn’t sound like your deployments, now’s the time to reassess how your team deploys Salesforce metadata. Ask yourself:
- Can our team see exactly what we’re deploying? Is it easy to compare the differences between the source and target environments?
- Is testing and static code analysis built into our tooling, so we deploy functioning and high-quality Apex?
- Are we alerted to common errors like missing dependencies in our deployment package, to help make sure the deployment succeeds?
- Can we build, clone, validate and share deployment packages to cut out manual deployment steps?
- Can we revert deployments easily with full or partial rollback?
- Can we see a full deployment history for team-wide visibility and an audit trail?
None of these things are possible with change sets, but they’re all easy with Gearset’s Salesforce metadata deployment solution.
2. Version control
Version control is critical for improving collaboration. Teams deploying org to org commonly block each other’s releases or overwrite each other’s changes. But with version control, everyone can work in parallel on their own feature branches, and deal with merge conflicts well ahead of each release.
To help your team adopt version control, gradually populate a Git repository with Salesforce metadata. Ultimately, all development should pass through version control, and your team should be able to release on demand from the main branch.
When it comes to Git-branching strategies, a simple feature branching model can be a good option to start with, where features are developed in branches then merged into the main branch.
For no-code teammates, adopting Git can be intimidating. But a DevOps platform like Gearset means they can commit to version control as easily as deploying from org to org — without needing to use the command line.
3. Automation for CI/CD
Once you have a reliable deployment process and your team is comfortable with version control, you’re ready for automation. Attempting automation too soon can create more work not less, since processes need to be stable and repeatable for automation to run smoothly.
You can automate a range of processes, including validations, deployments, testing, and backups. DevOps tools have a significant impact, but automation also must go hand in hand with cultural change. In particular, if your team wants to automate the release pipeline with CI/CD, you’ll need to be practicing continuous integration in order for continuous delivery to work effectively.
Effective automation obviously has a massive impact on time savings. But more than release speed, CI/CD is about release frequency. Being able to ship smaller releases more often allows for agile development, getting features into the hands of users earlier, and incorporating feedback into subsequent iterations.
Achieving CI/CD unlocks most of the benefits that teams are looking to DevOps to deliver. For a deep dive into the topic, download our ebook on CI/CD for Salesforce.
4. Automated testing and monitoring
Introducing CI/CD will always involve some test automation — changes should be tested and validated early on in the development lifecycle to avoid too many nasty surprises in upper environments. But more testing and monitoring can be automated, adding resilience to the release process.
- Unit testing should ensure that Apex classes execute as intended. Tests should be run at every stage of the development cycle, and then automatically in production, so that code doesn’t begin to fail silently.
- Automated UI testing makes sure that end users can interact with new configurations — and that no breaking changes have been introduced.
- Static code analysis checks that all Apex code conforms to the rule sets your team has chosen for code quality, consistency and security.
- Change monitoring alerts you to all metadata changes made to production (and other orgs if needed). This helps to identify hotfixes that need to be synced back to version control, or unauthorized changes that should be removed.
- Reliable testing needs test environments that match production as closely as possible. Whether you’re testing in a full or partial sandbox, seeding data from production is often the quickest way to get test data into those orgs.
5. Backup and recovery
With all your hard work developing Salesforce orgs, and all the critical business data held in those orgs, protecting your data and metadata with backups is an absolute must.
Teams practicing DevOps become experts at migrating data and metadata between environments, so the best approach for disaster recovery is to have backups and DevOps go hand in hand. With Gearset, your backup and release processes are tightly integrated, and all controlled from the same familiar UI. This familiarity will speed up your recovery time. You can also run backups on demand within the UI before a risky release, so that the latest data is secure if anything goes wrong.
It’s best practice to create a disaster recovery plan so that your team knows exactly what to do in a crisis. And having a plan is nowhere near as useful as testing that plan with sandbox environments, so everyone in the team is familiar with the process of recovering backup data and metadata. For a more in-depth guide to backing up your Salesforce org, read our free ebook on Backups for Salesforce.
Take the next steps for Salesforce DevOps maturity
Whatever stage you’re at, DevOps is about continuous improvement — iterating on your process to optimize your performance. Our free DevOps Assessment will give you tailored recommendations for your next steps as a team building on Salesforce. You can also hear more about DevOps strategy in this episode of the DevOps Diaries podcast.
If you’d like to see how Gearset supports you with every step of your DevOps journey and fast tracks your progress, get in touch to book a tailored demo or start a free 30-day trial.
