Description
Explore key findings from the largest ever State of Salesforce DevOps 2024 report. Find out how well teams are delivering for their businesses, and get data-driven insights into the challenges and opportunities of 2024.
Transcript
Hello, everybody. How's everyone's day? We got good. We got got some smiles. We got some nods. I like that. Cool.
So these slides look a little bit different to the ones that you've already seen.
Honest truth is I was a bit lazy and didn't wanna recreate slides in the new slide deck.
This is a presentation of the state of Salesforce DevOps survey results for twenty twenty four.
We first ran this a month or month or so ago at Gear Sets DevOps Summit. So, we run these once a quarter.
You can find those details online, gearset dot com slash events, I wanna say. But we discuss different topics every quarter. So like, think of it like a a mini two hour version of DevOps streaming. So that is why the library is a little bit different.
My name is Jack McCurdy.
Spoke a little bit yesterday about who I am during the opening keynote. I've worked at Gear Set for five years, and so I've kinda seen the ecosystem grow and change and evolve, across that time. And I spend a lot of time talking to customers about really about how they've improved their processes, over a journey. And hopefully, some of the results, from this survey that we run, we will be able to share a little bit more of a picture of how the landscape is shaping up.
So state of Salesforce DevOps, we've been running this survey since twenty twenty one. So every year we go out to the Salesforce ecosystem to ask them what they're doing in their day to day delivery practices, how they're releasing on the Salesforce platform, what shape that takes, and really try and identify, some trends and understand a little bit more about the direction that people are taking, when it comes to their deployments, whether that be different tooling or methods, whatever that may be. So we run this every year, and we look at a number of key metrics, which I am gonna go through here.
So the survey itself, esteemed from it, every year, like the attendance to DevOps streaming, which I referenced yesterday, is growing. So we had the biggest turnout in the twenty twenty four survey, that we've ever had. So we had just shy of thirteen hundred respondents, which is a really great number.
And the survey is global. So whilst you can see that sixty five percent of respondents are from North America, with varying degrees of percentages from other demographics, this follows Salesforce's footprints. They're they're Salesforce's own customer footprint. So their customer percentages in these territories are relatively similar to, what the survey came back with as well, which is so that's encouraging. It's not skewed, by us being a predominantly UK based company, or anything like that. So really representative data site data insight from across the ecosystem.
And continuing that trend as well, we do have representation from every single industry, which is great, with a significant uptick in transport and logistics.
And to me, that's a really interesting statistic. So transport does anybody in transport and logistics here in the room? No?
Transport and logistics has previously been one of the more kind of archaic industries, bit slow in their uptake of, new technologies and processes to drive their business growth. But that's the really interesting thing. So these older industries are starting to shift in the way that they process and these technologies that they use to help them deliver and innovate.
We're seeing that kind of across the board. Obviously, a large portion of us are invested in technology and work for tech companies, so technology also has a strong representation here as well.
In terms of company sizes, every every size, shape of company, also responded to the survey as well. So with all of those respondent demographics represented, what we've got is a really nice representative data set of the community and the ecosystem in general.
In turn with of the respondent roles, something else I talked about yesterday is that a lot of people in the room weren't Salesforce developers. They were admins, architects, many of you sitting here. And this year, we really, really, more than ever, have been able to debunk the notion that exists sometimes still that DevOps is only for developers. So you can see admins and devs responded to the survey, a rate of sixteen percent, across across the responded roles. So that's really encouraging.
And being able to debunk that DevOps for developers thing is something that we've been trying to achieve for a long time, and we are finally getting there, which is great. So with all of that said, really representative data data set that we can draw a lot of insight from.
As I was again, as I was mentioning yesterday, this is more of the more of the, statistic deep dive into things that I was alluding to yesterday.
But the adoption rate of DevOps best practices or different DevOps technologies has continued to rise. So this is great for for for us. Transparency is great for us, and it's great for everybody else that they are investing in these tools and technologies to support their Salesforce releases.
Adoption across all of these technologies has increased from last year, unsurprisingly.
And what's really great to see is version control here. So there's another talk later on today by EJ Sherman. He's gonna dive into, Git if you aren't familiar with it.
But that version control statistic, of eighty six percent of respondents either already adopting it or planning to adopt it this year is a really interesting statistic. Because if you've attended any of your sessions yesterday about CICD, or some more some more of the advanced DevOps practices, version control really underpins all of that. So we can continue to see this shift to the Salesforce ecosystem adopting those traditional software development best practices by underpinning their processes with version control.
With CICD being the next step as well, you can also see that, fifty three percent of respondents already do some form of CICD with many more looking to adopt that and continue that DevOps journey. And something that I talk about a lot is the evolution of roles and responsibilities and how you can continue to improve to improve on some of the statistics that I'm about to dive into. So you can really start to see that journey come through in some of these statistics as well.
The last main statistic from the adoption rates that I wanna highlight here is Salesforce backup. So data backup, sixty four percent of companies already have a solution. Yay. So if things go wrong, then they have a way to protect themselves.
I still think this number is too low. If that number is below a hundred percent, I think that is still too low as well. So it would be really great, to see that number continue to increase, but that has increased from fifty four percent last year. So the importance of having a resilient solution where people are able to recover from disaster incidents is on the rise too.
Spoke about some of the metrics. So DevOps is traditionally measured in four key metrics, which we break down into speed and stability metrics.
And these are metrics that were established by Google's Dora research team.
So the Dora metrics, stand for the DevOps Research and Assessment Metrics.
Speed and stability. So we're gonna dive into each of those now and explain a little bit about what they mean.
So deployment frequency is how often you do a deployment to production.
So deployment frequency is really indicative of how fast we are able to fulfill a user story. Request comes in and we're able to get that out of the door in x amount of time.
That deployment frequency, if we're able to release daily or every couple of days or at the end of every week or every sprint or what have you, then this gives an indication to how often we're able to do that. And the percentage of teams increasing daily to production has doubled from last year, which is a really encouraging statistic as well.
Teams who are only releasing a handful of times a year also have, so I hope that nobody in the in this room is still in those types of old development cycles where you do one major release every couple of times a year. Those teams that still do that are rare, and have from last year.
And that trend does remain a bell curve. So I mentioned there about, how often you do a deployment to production. Many of us still work in sprints, and the average sprint cycle tends to be about two weeks. So that trend really is a bell curve in terms of people that are deploying very frequently, rises a little bit, and then tails off again to those that are deploying very infrequently.
And this goes hand in hand with reducing that lead time for change.
So this is how long it how how long it takes for code changes to go from being committed in their first state to being in production. So with that lead time for change, what we will see improving that is if we're able to ship small and we're able to ship often. So I mentioned just now about teams that are only, doing one one or two major production releases a year. If we're able to break our code down, if we're able to break our features down, and deliver our value faster at to end users, then our lead time for change is gonna significantly drop as well.
That also has a benefit of enabling tight feedback loops. So engaging with the users, making sure that the right things have been built. If you're able to ship small and ship often your changes, then you enable that tight feedback loop and you can have a better experience for your org and for your users over time too.
And you can see here sixty one percent of those teams have a lead time of less than a week, which is a vast improvement of from when we started the survey back in twenty twenty one.
So if we move from the speed metrics, we move into stability metrics. So the change failure rate is a percentage of deployments that result in a failure or a fix needing to be implemented.
And this is the best indicator of release quality. So had a couple of talks already. One of the lightning talks this morning was about testing, and this is wholly indicative of a testing culture that a team has or and sometimes, may often not have. And we kinda see see that in this survey here as well. So you can see here eleven percent of teams, more than half of the time, have to solve a bug that's been shipped to production.
And then even eighteen more percent of teams, eighty percent more of teams are still struggling a little bit with twenty five percent to fifty percent of their deployments failing. Now it's not you're not gonna be able to catch a bug every single time, And these numbers are, you know, it's not all doomsday. It's not all doom and gloom.
This can, if you read between the lines, something that I mentioned yesterday is the practices that we're following and the tools that we're adopting are more all encompassing. So this, to me, is highly indicative of teams adopting a better observability culture, so being able to identify bugs. So these teams may well be catching bugs that they might not have previously found because they have the tools and technology in place to be able to identify those bugs. And otherwise, those bugs either go unseen until a user reports them.
A very common story. How did you find out about this bug? Oh, a user told me a month after it was shipped because that's the first time that they've hit it. That's happening less and less now too.
And the last metric that we were concerned with was the time to recover. So when we do identify a bug, and when we do have to fix it or move with a little bit more agility to get ourselves back into that state is how long it takes us to recover to that stable period. So So when we want when we do catch a bug, we wanna be able to restore to a previous version or roll forward with a fix quickly.
And there's a similar pattern here to the change failure rate in terms of how similar pattern to to the teams, the change failure rate about how they're able to recover as well. So quite a few teams you can see here are taking a long time, so more than several days. And this is one of those figures that when I mentioned about having a backup and recovery solution and why that statistic needs to be a lot higher and at a hundred percent is so that we don't have teams that are taking several days of disruptive business value when it comes to being able to restore. Because if you're spending several days trying to fix an issue or if the issue itself is not identified, then not only are you wasting your own time in terms of your own productivity and the cost that that is to the business, but the productivity that your end users are facing as well.
So it's really interesting to see that this these kind of statistics still exist, and maybe there's some more work and some research that we need to do, collectively to be able to put in effective disaster recovery plans to help us do that.
So eight percent of teams are categorized as elite teams in terms of their performance across all of those metrics.
But an elite team shows two things. So they show an excellent level of technical maturity, but they also show a high level of cultural maturity as well. And those teams very more often than not rated their collaboration across their team as excellent. So those elite teams were collaborating.
They were talking to each other, and they had consistent communication that allowed them to deliver with the agility that they wanted to as well as recover in those situations. And without those both, you can't really maximize your return of investment on the tools that you're implementing. So a well implemented tool will be supported by a great process and a culture that allows for people to come up to speed with those learning part of the journey. So we can see a lot of teams here are doing some form of DevOps training or release based training at least once a month.
And training regularly will improve your performance over time. That's just that's just a fact. And the fact that everybody is sitting in this room today or has attended DevOps streaming is testament to your investment and your company's investment of skilling you up to be able to do the work that you need to do that is vital, to maintaining the return on Salesforce investment and also those tools and technologies that you're putting in place.
But regularly engaging and training not only not only is good, but that will give you the confidence to be able to continue those next steps. The more that you engage in this training, you might feel more comfortable with adopting CICD processes or putting in a more robust disaster recovery plan, which will improve those metrics.
So the more frequently trained teams as well throughout the survey have better success metrics, and fifty percent of those teams that we surveyed as well, at least once a month, are fifty percent more likely to report a fifty thousand dollars return on investment more a month than those other teams as well. So this really does underpin how much value you get from it. It's not like like with anything, you buy a guitar, you don't play it, you're not gonna get better at it. And it's the same with your tools and technology if you're not continuing on that journey.
So with the metrics kind of out the way here, we identified four key things and key trends across the Salesforce ecosystem, that are really important to us this year.
Again, something that I was alluding to yesterday is that Salesforce DevOps is being democratized, so it's no longer just, developer activity.
And develop DevOps is designed to break down silos between your development team so that you can more efficiently release.
So we are definitely seeing that, and DevOps being democratized is a huge thing that I advocate for in getting everybody on that same path.
So seventy three percent of teams now report that they all ship changes in the same manner. So I I started at Gear Set five years ago, and when I was speaking to prospective customers, I'd ask them about their release processes, who was on their team, admins and developers. And more often than not, those teams would say, oh, our our devs ship their code via this command line, and the admins are languishing in change sets, and everybody's just having a bad time, not really talking about it, not really communicating about it.
But now seventy three percent of teams are all following the same method, whether that be through tools or, some of the native tooling that's out there as well. Those teams are following that consistent practice across that. So DevOps being accessible to everyone is really important and has become more prevalent as the years have gone by.
This empowerment of the teams and everybody in the team following that process and feeling bought into that process, nobody's left doing something on their own or feeling isolated is really good for your team's morale and productivity in the long run. And for those teams that are deploying different metadata outside of the usual process, if teams are not following those processes, it comes down to the metadata that's been left out, and some metastases than others is trickier to deploy than others. Like, if anybody's wrestled with a profile deployment, then you know how painful that that can be.
Only one percent of teams reported that they split their releases based on what the role type was, so being app and or developer.
There was a bunch of responses, but these were the most frequent. So profiles and permission sets are still those ones that get left out or have to be deployed in a different manner, Which leads me on to point number two, migrating to permission I should say permission sets. May migrating to permission sets is still a key priority for all teams.
So for context, last year, Salesforce announced that they were gonna sunset profiles for spring twenty six release. That's no longer the case anymore, but that was the plan.
Eighty percent of Salesforce teams are still planning to do that migration by the original end of life date.
So they've got their selves prepared, and they were able to make a plan to make that happen, which is really encouraging. And those that had those unified processes where admins and developers were deploying in the same manner were the ones that were more likely to be able to hit that target date and have a plan for it.
And those elite teams that I mentioned earlier, they are twice as likely to have already done so and migrated to permission sets or to have that plan as well.
And I really like this slide because I really do think it demonstrates the challenge that profiles bring to deployments. So teams that have already migrated to the permission sets are deploying much easily much easier and much simpler with those deployments, and it's taking less than an hour to do those deployments than those teams that haven't done that. And those teams that have no plan are kind of languishing up here in those long deployment times, which we're all trying to look to avoid.
Downtime from deployment can still be a big issue, and the faster we can do those releases, the better for everybody.
The third issue is that compliance requirements are on the rise. So profiles, permission sets, access, security, all of those things are playing a bigger part in our roles, the more custard customer data that we're looking after. Our customers wanna know that their data is in safe hands, and we, as organizations, may well have compliance requirements to take into consideration.
Last year, more and more businesses were relying on Salesforce to handle more and more of those processes.
As I'm sure most people are familiar with in this room, Salesforce kinda sneaks into your organization. First, it first, it might handle your sales, and then it ends up doing your service. And it's your employee platforms, it's commerce cloud, whatever it is, the Salesforce platform really does scale and grow. Now, you know, you know, Salesforce AE is very keen to get you onto as many clouds as possible and work with you to expand that. And that is definitely what we're seeing across this survey too.
As those orgs expand, the dataset intensifies, I guess, in terms of the level of data that you have, the PII that you might have if you're in a health care based organization.
Eighty two percent of teams, Salesforce teams, already have to comply with one regulation or another, whether that be, HIPAA or in the UK, GDPR or the CCPA or whatever framework that they have to do. Then fifty two percent of teams are also gonna try to add another one onto that. And with robust processes or processes that have high levels of visibility into them, it's gonna support that ability to stay compliant with those regulations.
Rarely are teams flagged in their compliance audits, which is excellent, especially for those seeking to comply with more regulations, down the pipe.
And this is kind of bucks the trend a little bit. So you would think with bigger Salesforce teams, with more moving parts, more admins, more developers, architects, etcetera, that those teams would find it harder to comply with those regulations with so many moving parts. You know, there's that age old adage that the bigger they are, the harder they fall.
But there's strong positive correlation between the size of the Salesforce team and the number of frameworks that they need to comply with, And the more you have to comply with, like, hit that you'll fall short, and that kind of analogy.
But those bigger teams approved that they themselves shown impressive spike in their audit performance, and those teams were also the most likely to say that they would benefit from some form of regular or specific compliance training, which just goes back to illustrate the point of those teams that are training more often are gonna be more successful.
And those data management tools are the key to compliance.
For teams struggling here, it's a sound and necessary investment. A lot of the backup tooling out there, whether it be OWN, GearSet, or others, are really supporting those organizations and being able to handle their data effectively, securely, and safely.
And those with compliance requirements on the horizon, if you don't already have them, then backup is gonna be the first place that you are gonna wanna look.
And the fourth and final finding from this survey is that Salesforce specialist backup solutions offer the best protection as well. So waxed lyrical about backup enough already.
But different solutions have different upsides and different downsides.
And Salesforce specific solutions will not only back up your data, so all that critical information that you hold about your customers, but your metadata as well. Data backup is a two pronged approach. You need to have all that configuration stored safely, so that the event of a a data disaster, you're able to restore the metadata if the metadata is being corrupted or changed unnecessarily.
Eighty percent of eighty seven percent of teams have a solution or plan to adopt a solution this year, and there's a range of options out there, Salesforce specific backup and restoration, Salesforce's own backup, Salesforce's data export, or the generic providers that might back up your Microsoft three six five or other platforms as well.
And in order for those solutions to be worth their salt, your backup is only as good as your ability to restore from it, and the recovery point objective that you might have. So your recovery point objective is the last point that you can restore your data from. For some, that may be a might maybe twenty four hours.
For a lot of teams with high turnover, if you're using, field service lightning or you have a lot of case management or you have a lot of interactions with your business on an hourly basis, an hour might be the only acceptable point that you can recover from, with that high business day of turnover.
And with those third party Salesforce solutions, you can see that they're backing up way more frequently than if you are doing Salesforce's data export. If anyone is still doing the Salesforce weekly exports and think that that's not gonna have some major level of disruption in your business if you do have to recover, then you might wanna think again.
And those with those third party solutions as well, I mentioned, you know, it's only worth its salt if you can actually restore from it. And those with those third party solutions are able to restore much, much, much quicker in hours compared to days or even a week or longer. So think about that level of disruption. How, if you have experienced data disaster and you've had to do a restoration, how much pain and how much time, how much effort does it take to restore from?
And it's not a case of if you've experienced it or, if you will experience it. It's just a case of when in a lot of these situations as well.
And those Salesforce specific solutions are designed to handle those complexities.
Deployments are already difficult enough on Salesforce, and that metadata that I was talking about is the foundation and the basis for your org. Those Salesforce specific solutions are designed so that you can restore the most effective way possible. They understand metadata. They understand the data model of the Salesforce. They understand all of those complexities that the generic vendors provide.
And, you know, the the less said about data exports and wrestling with CSVs, the better.
As I mentioned, it's not a case of if you experience data backup, it is a case of when.
But those that haven't experienced data loss in the last year, have been using a third party Salesforce tool, as well. So those figures are really highlighting the importance of having Salesforce specific solutions. Salesforce, as we know, is an amazing technology, but it's also a very bespoke technology that requires a lot of care and a lot of hand specific handling for those challenges.
And those companies that are with a Salesforce third party solution, like Gearset and OWN and some of the others that I mentioned there, are in really good stead to have, to be in good good shape for when this happens, and we'll have that culture of a security and compliance mindset too.
Gearset themselves has specific tooling. Thirty two percent of respondents were Gearset customers, and Gearset customers are also in the lead across all of those Dora metrics that I mentioned there as well. And a good part of that is the number of partnerships that third party solutions can create with you to be able to effectively restore from disasters disaster recovery scenarios. We help customers plan their data recovery strategy. We plan help them plan their Salesforce release strategy.
And, of course, if you haven't had this shield enough already, you can try GearSet free. If you're not a GearSet customer already for thirty days, just spin up a free trial.
The report and all of its excuse me. The report and all of its findings I'm alright, I think. The report and all of its findings are available via that QR code, so I'm gonna leave that up, for y'all to scan.
If you need it, there's some really interesting insights in there, and you can use that to see how your team stacks up against the wider industry. And if you have any questions or if you'd like to participate in the next state of Salesforce DevOps report, that will the survey comes out November, December time, and there's usually a nice juicy raffle prize to be gained from that too. So there you are.
Thank you.
