Every Salesforce team faces unique challenges, but we regularly see a common theme: teams are generally being asked either to release faster or more securely. Unsure what to prioritize as they scale their releases, more teams are beginning to feel tension between the velocity and resilience of their pipeline.
Measuring the velocity and resilience of Salesforce releases
At a high level, velocity refers to the speed of development and release, while resilience refers to the security and recoverability of your release pipeline. When it comes to measuring velocity and resilience, it’s useful to draw on Google’s DevOps Research and Assessment program (DORA).
DORA outlines 4 key metrics to measure the maturity of a DevOps release process:
- Deployment Frequency: how often an organization successfully releases to production
- Lead Time for Changes: the amount of time it takes a feature to get to production
- Mean Time to Recover: the time it takes to recover from a failure in production
- Change Failure Rate: the percentage of deployments causing a failure in production
Although the DORA metrics are designed as a complete DevOps assessment, we can group them in pairs to measure velocity and resilience. Deployment frequency and lead time for changes assess the velocity of a release pipeline. Mean time to recover and change failure rate assess resilience.
Release velocity versus resilience?
Teams who need to get functionality out to users quickly sometimes feel like the easiest approach is to skip some of the measures that make their pipeline more resilient. On the flip side, there are teams who have to work within strict security frameworks and feel like keeping their pipeline as secure as the business needs just isn’t compatible with fast delivery.
Actually, velocity and resilience work together; for a fast pipeline, resilience is vital. A team that focuses on speed at the expense of ensuring the resilience of their pipeline will eventually reach a plateau: more time will be spent resolving issues and firefighting releases, which will cancel out the time saved by attempting to release quickly. On the other hand, being overly cautious can completely stall releases, when a resilient DevOps process is actually meant to enable greater velocity.
Salesforce DevOps performance matrix
Velocity and resilience are often positively correlated, but can be independent of each other, so plotting these metrics on a graph is the most useful way to show a team’s overall performance.
For example, if a team releases multiple times a week but has no source control, automation, or backup — and they have to troubleshoot most of their releases — their velocity/resilience matrix would look like this:
One approach doesn’t fit every Salesforce team
While velocity and resilience go hand in hand, every Salesforce team is different and will usually favor one more than the other. Some teams put emphasis on delivering at speed rather than delivering perfect releases. Change failure is seen as par for the course with a ‘move fast and break things’ approach — it’s better to deliver functionality quickly and iterate on any issues than to delay releasing until the package is perfect. For other teams, releasing to production when a package may be faulty wouldn’t be acceptable to the business, so taking extra time to test the package is preferable.
When you’re deciding whether to lean towards velocity or resilience, the key influence is your company’s risk tolerance. In the context of Salesforce development, risk tolerance is the willingness to accept an imperfect release to production.
Ideal risk tolerance
Each team will have an ideal risk tolerance that determines their preferred position on the velocity/resilience matrix. There are many factors that can determine where this ideal will fall, including:
Compliance frameworks. A lot of teams, particularly those in highly regulated industries such as finance or healthcare, have to ensure their release process is compliant with various frameworks such as the Sarbanes-Oxley Act of 2002 (commonly known as SOX). These teams will likely lean more towards resilience.
Tooling. The DevOps tools a team uses can make a process inherently more resilient. For example, a team using version control as their source of truth can revert to an earlier version if a release is faulty. Resilient tooling gives the peace of mind that a release is as secure as possible and can be resolved easily even if something does go wrong. The more resilient their tooling, the higher a team’s risk tolerance is likely to be.
Situational risk tolerance
While we wouldn’t expect a team to move too far away from their ideal risk tolerance, there are times when risk tolerance can change on an ad hoc basis. This situational risk tolerance might come into play for the following reasons:
Capacity. If an influx of development requests are submitted or the team is short-staffed, a team may err more on the side of speed to deliver quickly and ease backlog. But it’s worth noting that capacity may become a determining factor in baseline risk tolerance, if a team is always over-stretched.
Urgency. If a critical piece of development is needed to unblock users, the development team may need to focus on delivering functionality even if it isn’t perfect or hasn’t been as rigorously tested yet.
Release size. When a release impacts only a small section of the production org’s codebase, pushing a deployment through quickly and skipping some usual security measures may be seen as lower risk. Conversely, extra precaution — and time — may be taken to ensure the release is stable if it’s particularly large or impacts many objects.
Is there too much risk in your Salesforce pipeline?
Although risk tolerance will vary from team to team, there are some risks that simply aren’t worth taking. Every team should have data and metadata backups. Every team will benefit from version control. And no team should be developing directly in production. If you’re looking to improve your release pipeline and have any of these risks in your workflow, you should focus on resolving those as a priority.
Your Salesforce velocity/resilience matrix
The journey to DevOps maturity and achieving your ideal velocity/resilience balance should be taken one step at a time. Trying to take on too much at once will actually be more challenging and likely slow you down.
For example, some teams try to introduce version control and automation at once; unless you’re up-to-speed with version control and your deployments are reliably successful, any automation flow will begin to fail regularly and you’ll lose time debugging. So it’s unsurprising that Google’s 2019 State of DevOps report found that only 9% of teams reach ‘elite’ performance if they try to implement DevOps in a single, big bang approach. Improving your release pipeline in small, manageable stages is the most successful way to reach DevOps maturity.
But working out the best next step for your team can be hard. If you’re keen to understand how your development process stacks up and the best way to make your DevOps setup more mature, secure, and speedy, take the Salesforce DevOps Assessment.
After answering a few quick questions, you’ll get a free report plotting your performance on the velocity/resilience matrix, as well as a breakdown of how mature your DevOps process is. Plus, we’ll give you tailored next steps to improve the performance and maturity of your process. Here’s a sneak peak:
Need help? Gearset can support you — wherever you are in your Salesforce DevOps journey — book a consultation with one of our DevOps experts today.
