Keynote: Mature your DevOps performance and processes

Share with

Description

DevOps is a journey, not a destination. Rob Cowell, DevOps Advocate at Gearset, advises on how you can keep improving your Salesforce DevOps process and performance.

Topics covered:

  • How the DORA metrics apply to Salesforce DevOps
  • Balancing speed and and security as you mature
  • Core DevOps processes including source control, automation, backups and testing
  • Continuous improvement of your process and red flags to watch out for

Learn more:

Related videos

Transcript

So this time, our theme is all about leveling up your Salesforce DevOps and looking at the ways to build upon your existing processes to take you to the next level of DevOps maturity.

Over the course of all of our talks today, we're going to be looking at strategies and techniques for getting more out of DevOps and exploring how to take a more crafted approach that better reflect your unique business needs, and that can really pay dividends.

So as is traditional in these types of presentations, a quick introduction. My name is Rob Cowell, and I'm one of the DevOps advocates here at Gearset.

That involves engaging with you, the wider Salesforce community, to help guide and advise on best practice for Salesforce DevOps, to bring awareness of the current trends that we see across our customer base, and to support your journey through to DevOps maturity for Salesforce.

So to kick things off today, I'd like to give you a bit of a quick overview of some of the areas that we're gonna be looking at, not just in this session, but across all of our sessions.

I'm sure by now you've heard folks like me constantly reminding you that DevOps is a journey, not a destination.

No matter where you are along that Salesforce DevOps journey, there's always gonna be some potential for a next step, and that's what we're gonna be exploring today.

It's vital to continue to mature the cultural mindset, the processes, and the tooling for delivering change as quickly, accurately, and efficiently as possible.

To do this, we're going to look at some of the common areas that can be easily overlooked when it comes to defining your DevOps approach, be that offline or online, process or technology.

We'll also dig into the benefits of tailoring the way that you handle your Salesforce DevOps, ensuring that it aligns to your business, your release cadence, and the way that your teams are best suited to working.

There's no one size fits all here, and we'll see some differing viewpoints and techniques that you can use.

Then finally, in acknowledging that Salesforce DevOps is still very much a journey, we'll explore some ways to keep the pace and ensure that you continue successfully on your chosen path.

So fundamental to improving your DevOps performance are metrics.

Measurement allows us to baseline where we are today and to track improvements as we progress.

By being able to see what we're doing well and what we're not doing so well, we can really focus our efforts and redouble on them. So to that end, we recommend a set of metrics that are very closely aligned with Google's store metrics.

Lead time for changes. This measures how quickly a change can be delivered to production once the work to create it's complete.

Tracking the time from developed to deployed gives you an indication of how quickly you can deliver and often helps to highlight where any bottlenecks may exist.

The change failure rate. This measures the percentage of changes that require subsequent work to either deploy correctly or that require remediation after going into production.

While one affects the deployment itself and the other is post deployment, both impact on the quality of the changes you deliver to your users, and both require additional time and effort to put right, so we tend to group them together.

The deployment frequency measures how often changes are put through the various stages and into production.

By making smaller, more atomic changes as a bigger piece of work, not only do you increase this frequency metric, you're also able to get your changes into source control earlier, which gives you that additional safety net of being able to roll back if you need to. The trick to excelling in this metric is to look at your deliverables as a collection of smaller components that can stand in their own right, but be mindful of dependencies and permissioning as you do so. The true skill here is applying your Salesforce expertise to identify those logical groups of metadata changes that can move independently through your DevOps cycle.

The mean time to recovery, now this last one is measuring how quickly you can return from an outage, a data loss, or a bug. Much like the other metrics, this can be broken down into a few stages, how long it takes to notice an issue, how long it takes to identify the cause and remediate it, and, of course, how long it takes to recover from any data loss by restoring from backups.

These factors all combine to give the overall time it takes to get back to business as usual.

This mesh metric should be viewed as indicators of success, but it's important that we achieve a balanced mix of speed versus stability, and that's why the metrics are designed to measure both.

Lead time and frequency metrics demonstrate your pace of change, whereas change failure rate and recovery time metrics demonstrate the quality of your deliverables and your resilience to problems.

For some teams, adopting the start up mantra of move quickly and break things works for them. It allows them to get peak speed, try new ideas, and get them in front of their audience rapidly.

This affords them a very quick feedback loop, and they can be much more responsive to change.

For other teams, such as those in regulated industries like financial services or health care, a slower pace is favored in which stability is the most important factor.

In this scenario, there's no point in lots of rapid deployments and getting changes in quickly if they're not up to the required standards and require constant rework.

But here's the reality of finding that correct balance and leveling it up you're leveling up your Salesforce DevOps. A truly mature DevOps process achieves the speed of delivery by achieving the accuracy first. Get your changes solid first time, passing automated tests and peer reviews, and you magically achieve that deployment velocity because your changes are production grade and ready for release earlier.

It's this constant balance between velocity, accuracy, and resilience that forms part of the reason why there's no definitive DevOps process for Teams.

There are many factors that can determine the shape of your Salesforce DevOps, team size, varying levels of technical comfort in the team, the overall appetite for risk in your organization.

These cultural elements are also paired with technical challenges, such as possible dependencies on non Salesforce systems for a larger project, for example.

For these reasons, it's important that your DevOps process scales as your business scales.

While using change sets is possible for a solo admin, as your team grows, it becomes less sustainable as a deployment approach, and your metrics, when you measure them honestly, will very much reflect this.

On the flip side, trying to rush into an enterprise scale end to end DevOps pipeline ahead of time will have an equally detrimental impact on your metrics unless your teams at the scale that can support those various processes.

It's vital that we recognize that the shape of your DevOps is never set in stone, and it grows organically as your needs grow. So if there's one thing that I want to convey to you today, it's that there's no definitive right way to implement DevOps.

When we look at this maturity path, it's important to acknowledge that it's entirely acceptable for teams not to need all the elements.

I like to think of it as a list of ingredients to select from in order to form your own unique recipe.

Sure. There's core elements that form the foundation, such as source control and backup, but the real value comes from applying those principles in a way that supports the way that your teams operate.

So So let's look at some of those DevOps ingredients, starting with the core elements that support the others.

Top of the list in my mind always should be the adoption of source control.

This single element transitions you from just deployments to actual DevOps, and it's the backbone of every other step that you take as you level up your Salesforce DevOps process.

But even here, there's paths to take and decisions to make that will ultimately determine the shape of your process.

The choice of branching strategy for your source control, for example, has a significant impact on the rest of your process, and so care must be taken to ensure that it's best suited to your team's way of working.

Our free self loading site, DevOps Launchpad, has a module devoted to Git branching strategies, and there you can learn some more about some of the common choices together with their strengths and their weaknesses.

The next significant step in leveling up your Salesforce DevOps is unlocking the power of automation, whether that's the simple steps of creating jobs that notify you of changes to your orgs so that you can monitor those updates, or whether you go to the other end of the scale for a fully automated CICD pipeline that delivers the change through your environments as soon as they become available.

Automation affords you the potential for huge productivity gains.

But it's important to reiterate that not all processes are suitable for all teams. Remember, not all teams are the same size, have the same release cadence, or have the same checks and balances requirements along the way.

I'd advise that for those of you maturing your DevOps processes and looking at the next steps, you should continue to take a measured approach and not try and leapfrog your way along the DevOps maturity journey.

The third fundamental part of a mature DevOps process and perhaps the most commonly overlooked is backup and restore.

This delivers on the metric I mentioned earlier, the mean time to recovery, and for this reason should be considered an intrinsic part of any DevOps process rather than a separate process.

A basic backup will certainly help you towards your recovery objectives, but a truly mature DevOps process will have a more comprehensive approach to backup.

This means automated backups for your primary backups, but also the ability to make manual out of band backups before you undertake major changes.

It includes monitoring for data anomalies, such as unusual patterns of data changes, deletions, or additions.

It means being able to restore both metadata and data efficiently with steps that are easy to follow when you need it most and that allows a more precise restore from backups rather than completely overwriting everything to a prior state.

Mature DevOps practitioners restore with scalpel like accuracy, not by wielding a hammer.

The final pillar of DevOps I want to call out as foundational is the need for thorough and robust testing of your changes.

Now those of you that are used to a more pro code approach to Salesforce changes will know that Salesforce mandates a certain level of test coverage for Apex code as part of any release to production.

But there's improvements in this area that can be made in the low code space as well.

A mature DevOps process should be treating Salesforce's requirements as a bare minimum and strive for as close to a hundred percent coverage as possible, platform limits notwithstanding.

You should also be ensuring that your test changes aren't just Apex code. This means looking to exercise tests for your lightning components using Jest. It means looking at ways of testing your flows in an automated way, something that's difficult to achieve currently, but definitely something to be looking towards in the future as Salesforce is introducing the ability to create flow tests from debug runs.

Robust testing across all your Salesforce changes will drive your change failure rate down, which in turn improves your ability to deliver that change to your users and customers.

Now while we've agreed that DevOps shouldn't be a one size fits all approach, there's some key areas that we'd recommend avoiding. The key is to see them as recommendations rather than necessities, but they come from a background of working with DevOps teams of various sizes and maturity.

For example, when taking backups, we propose that you should back up not just your data, but your metadata too. Having the correct schema and relationships in place ahead of that data will ensure a much smoother path to data recovery and restoration when needed.

Another potential red flag is not ensuring all changes going via source control where possible and allowing changes to be deployed outside of your DevOps process.

Now these last two are symptomatic of a lack of team alignment on the process, and that leads to another fundamental thing to avoid.

Don't tackle the technological aspects of DevOps without ensuring that your cultural and collaborative processes are in place.

Now at this point, many of you is gonna be at various stages of your DevOps growth. But no matter how far along that path you'll be, there's always a time to take stock of your DevOps performance and look at the next steps. How do you identify when to take that next stage, and how do you redact?

We've looked at letting the metrics stock drive your direction for a data driven approach to decision making, but it's important to remain flexible.

DevOps is about continuous improvement just as much as it is about continuous integration, and your processes should not be so firmly entrenched that you stagnate.

By all means, allow each iteration of enhancements to bed in and ensure your teams are getting the most out of that growth. But once you reach stability, look at where you can take things next.

The top performers in Salesforce DevOps, those with the fastest route to delivery with the least deployment issues, recognize that it's perfectly valid to revisit the pro the, revisit their approach as their goals change.

Don't be afraid to tear things down and rebuild if it means you get a better alignment and better performance.

But please, please, for all our states, plan it properly first.

This same dedication to planning could be said of the other core tenant of DevOps, backup and recovery as well. Do regular disaster recovery drills validate your procedures, both the offline and the online, measure your time to recovery, and look for potential improvements.

Carry out these tests soon and often. Don't wait until the wheels fall off to find out that your ability to recover is not up to the task.

Now I realize that I've talked a lot about the high level approaches and the principles, but these theories are backed up with solid data, and I'd like to share some examples with you that will bring to life some of the areas to focus on as you level up your Salesforce DevOps.

Of the teams that hardly ever struggle with their CI jobs, ninety one percent report a larger Salesforce ROI thanks to DevOps, and seventy percent of those fix bugs within a day.

On the flip side of that, seventeen percent of teams don't back up their data at all, and that rises up to twenty percent for not backing up metadata.

And the twenty nine percent of teams that just simply export their data every once in a while using, whether manually or using data export, they're not in a position to restore that data quickly either. Remember, a backup's only as good as your ability to quickly and accurately restore it.

And finally, twenty one percent of the teams that we surveyed report that they use unmasked data from their production orgs in their testing environment, which potentially exposes them to data leaks, accidental emails, and more.

It's not all a tale of woe, though. Organizations that have taken Salesforce DevOps to heart and actively worked on continuous improvement have reaped the rewards.

Veolia, the leading multinational waste, water, and energy management company, have seen their deployment times drop down to around ten minutes even for complex changes, a saving of a hundred hours every two weeks.

This in turn has reduced costs as their need for outsource resources to manage the process has reduced and increased productivity as their developers are freed up for other tasks.

These are real world tangible examples of how leveling up your Salesforce DevOps has a potential to level up your overall productivity and efficiency within your business.

So as we wrap up today's keynote, I want to leave you with some additional resources that you can use to build on some of the ideas I've shared with you and use them as a springboard for taking action. First is our free training resource, DevOps Launchpad, which covers many topics in much more detail than I have time for today, and not just the technical aspects, but on helping you design your strategy as well. And then secondly, we offer a free DevOps maturity questionnaire, which allows you to benchmark your current process and help steer you towards areas to focus on next as you continue to grow your Salesforce DevOps.

So the links for both of these are shown there along with some QR codes you can quickly scan. I'd love to leave them on screen as long as possible, but we do have to keep the momentum going with our sessions today.

So at this point, I'd like to thank you for listening. I wish you a great DevOps summit as we head into our speaker sessions, and I shall hand back over to Tony. Thank you very much.