As time passes, organisations that are using salesforce have become more and more dependent on it. Salesforce DevOps is focused on ensuring administrators and developers can release updates and go through the software development lifecycle as efficiently as possible, with the least defects and user interruption. Jack McCurdy, Salesforce DevOps Advocate at Gearset, features in today’s episode of the Salesforce Posse podcast to share his experience as a salesforce advocate.
Jack shares knowledge of DevOps throughout the salesforce ecosystem. He has spent the last few years working with businesses to establish DevOps teams and procedures, which are essential for delivering Salesforce installs successfully and fostering both business growth and customer satisfaction. His passion is supporting the creation and maintenance of outstanding cultures that serve as the pillars of DevOps best practices.
During today’s conversation, we explore what DevOps is, what it provides people, and Jack’s experience working at DevOps. Jack dives into what common problems people want DevOps to find solutions to and how they make it simpler and errorless. Furthermore, he discusses the importance of metrics when measuring success and maturity, and wrapping up the conversation, Jack dives into how communication can solve problems and make a better workplace for employees.
At Salesforce Posse, we interview influencers in the Salesforce ecosystem so that we can gain a better understanding of how to excel in a career path from a Salesforce Admin or Developer to an Architect.
[04.44] DevOps – DevOps is a set of practices combined with software development and IT operations. Starting the conversation, Jack dives into what DevOps is and how they help people to identify problems sooner and solve them.
[06.10] Problems – Jack dives into the common problems people come to DevOps for solutions.
[13.14] Backups – Having backups and the mental health benefits of DevOps. Jack dives into how Dora metrics are used in DevOps.
[15.58] Metrics – Jack explains how essential metrics are when measuring success or maturity.
[21.33] The phoenix project – A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim.
[22.42] Mindset shift – Role changes can be difficult in the beginning. But, with the right communication, you can change the environment for employees and build a level of maturity in the organization.
Resources
Sponsored by AdminToArchitect.com
Transcript
Francis Pindar (A2A) 00:00
Hello, my name is Francis Pindar and you are watching or listening to the Salesforce posse podcast. Now, I did catch up with somebody who grabbed me that I was chatting to. And he didn’t realize you could watch this podcast from Spotify. So if you are listening to this on Spotify, bring up your phone or your computer, and you’ll be able to see me in Technicolor. So the Salesforce posse podcast is where I speak with Salesforce industry influencers to gain a better understanding of how to excel in a career path from a Salesforce admin or developer to an architect. And a couple of weeks ago, I was invited to speak at DevOps dreaming, an event dedicated to learning more about Salesforce DevOps, so that we can deliver Salesforce changes more efficiently into production, monitor and learn from those challenges so we can improve the experience of our users and teams implementing on Salesforce. So I did a talk on my Salesforce DevOps journey, but I managed to grab some time with Jack McCurdy, who is performed gearset and is sponsoring this Salesforce streaming event. So if you’re interested in learning more about Salesforce, DevOps, or even have no idea what I’m talking about, when I say DevOps, then I think you’re gonna get a lot of value from this conversation with Jack McCurdy. So without further ado, let’s go. So I am here with Jack. And we’re here at DevOps, dreaming in London learning all about Salesforce DevOps, a maturing model of how you can kind of be more efficient as the way you do stuff in Salesforce. And you are the DevOps guru. That’s why
Jack McCardy 01:49
we had a conversation earlier about yours.
Francis Pindar (A2A) 01:55
Yeah, we did a panel. The panel discussion? I
Jack McCardy 01:58
think it was yeah, it was part of the panel. Yeah, yeah, we
Francis Pindar (A2A) 02:01
did a panel discussion, which was at was really great actually burn out in a tech and it said, yeah, there are no Salesforce gurus. No, it does not exist. The platform is just too big. And you don’t want that pressure. You don’t? Yeah, it’s a really good session. And so how’s it been? So far? Actually?
Jack McCardy 02:20
Yeah, the conference has been amazing. At gearset. Like, we’re really proud and privileged to be members as communities. So it’s great to be able to put this on and do that for them. And, you know, we take great inspiration from things like London’s calling, and all the other community conferences that we get to go to around States and in Europe, and to see that come out here as well and have it be so well attended. And London is really nice to see. And the speakers have all been amazing. So far, we’re only halfway through. But everybody’s had well attended sessions really engaged. And it has prompted some good conversation from what I’ve heard.
Francis Pindar (A2A) 02:54
Yeah. And that’s been quite interesting. Because that even like, you always get kind of stuck in the tech a bit, I think, and just kind of stepping back and kind of going well, I actually, you know, there’s other stuff. There’s the kind of the mental well being piece of DevOps around well, actually, I want to get this stuff into production quicker. From my own well being of seeing I’ve succeeded in stuff and things like that, which I kind of didn’t even really think of, I suppose. Yeah,
Jack McCardy 03:20
for sure. I think that’s one of the big DevOps can play such a big part in, in that you know, mental well being as well as we’ve all been there and late nights because of a change set or failed deployments or and you know, wrestling until 123 Am isn’t an uncommon story that we’ve heard. So finding a way to address that and help people go back to their families or be able to do their hobbies in the evening or what have you plays into that too, as well as that gratification when you see the deployment succeeded. Deployment succeeded button, the fish completes.
Francis Pindar (A2A) 03:53
So okay, so if you are if somebody is coming in this completely new and has no idea what we’re talking about, when we talk about DevOps, what would you say DevOps is? So
Jack McCardy 04:04
DevOps, when you distill it all down to the basics is really to really succinctly it’s the better way of delivering software is ultimately what it comes down to a set of practices and principles that allow for efficient, streamlined delivery. And the word itself is a combination of software development, IT operations, so was taking the best practices from both of those things, and combining it to software delivery team or Salesforce delivery team that’s really firing on all cylinders and can focus on doing the impactful work, the building of features and the user stories or
Francis Pindar (A2A) 04:40
trying to repackage for the 40th time fourth that thing into production.
Jack McCardy 04:46
Absolutely. So it’s all about speeding that process up but doing it in a safe and safe and controlled way. You know, things break. Even in a great DevOps process. Things still break that still happens, but a great DevOps process will help you identify those things sooner and hopefully be easier to resolve if it’s being done. Right. So that’s it in its simplest form, I guess. So okay,
Francis Pindar (A2A) 05:06
so what are the kind of common things that you see people call on problems they’re trying to fix using DevOps.
Jack McCardy 05:12
So a lot of what it comes down to is the pain that people experience when they have a lot of manual steps, there’s, there’s a large percentage of teams that we see have issues when it comes down to things that either have to be, you know, recreated manually in other environments, you know, you you see, to do something in sandbox. And then so many times you hear, let’s recreate it in production manually again, and you know,
Francis Pindar (A2A) 05:37
it’s like a vicious circle that I’ve been at. It’s like the deployment failed. And you know, this is hard, so they will do it manually next time. And so then your manual worksheet and steps grows and gets bigger and bigger, because always scared doing that, you know, anything other than manual.
Jack McCardy 05:53
Exactly. So either manual steps, which are tedious, even if you’re not manually recreating things in production, you’re then creating a change set or creating a package, which then needs to be redeployed to other places, you have folks that are looking to to not have speaking of lists. Actually, if you think about all the message changes that you make when you’re building something, how easy is it to forget one of those things? And by implementing a process tooling, or what have you, it’s about finding ways that you can make that process simpler and easier and less prone to errors that don’t really need to be
Francis Pindar (A2A) 06:24
Yeah, I think I did a talk earlier on. And it’s like, one of those classic problems is that, you know, developers pull out that profile meta data, but not all the fields and then you miss the field field level security in the profile, you push the profiles back, now you’ve overwritten it in your source code control. That’s right. But then you try and deploy it and the deployments fine. Just didn’t include it. Yeah. But it’s actually you know, you’ve got usability issues, because you just can’t access those fields anymore.
Jack McCardy 06:50
For sure. So and then I think if you think about those, those things, and what we’re actually talking about is actually saving people a lot of time and effort is ultimately what it comes down to is the biggest number one reason people people come to us and say, we need to do something about this is because it’s taking the 9, 10, 11, 12 hours a day, you know, for one production deployment. And they might be doing that once a week or two weeks, or if they had a long running project, then we’re talking days worth of deployment time, so literally days worth. So that’s really what it comes down to, there’s
Francis Pindar (A2A) 07:23
actually we were just talking actually, before the podcast, it’s like, do I do edit my own podcast now. And it’s like I used to do and I don’t anymore. And it was a bit of that it’s the same kind of thing where it’s like, well, it’s not what I’m good at, I’m good at the you know, in Salesforce world, doing the configuration, doing the coding, do the building, not packaging, and trying to get it into the next environment, you know, give that to some other tool or practice or a way of working, that makes everything more efficient. And also, it’s more enjoyable, because you’re doing the stuff you love, rather than trying to hack around with change sets, or whatever it is.
Jack McCardy 07:54
That’s it, we’re chatting a little a little bit earlier on about that enjoyment. And that fulfillment, it’s not just a ticket, the green light, it’s just, if I’m not doing that, then I am doing something I’m learning something new, maybe on trailhead, or what have you, I’ve got to build a new feature that I’ve not done before I can actually focus on that not worry about business as usual stuff that gets in the way. And a lot of the time that those things do get in the way, and can either either hunt for enjoyment of your job, or your ability to skill up and excel at something or learn something new.
Francis Pindar (A2A) 08:24
Yeah, I think it’s also we kind of talked about in some of the other sessions was around like constraints in the process. And actually, you can have just one thing, one constraint in that DevOps process, which even if you optimize everything before or everything after, it’s utterly pointless, because everything’s feeding through on the same track, and it’s all everything’s gonna hit by the same constraint, and you’re still going to be limited by this. And it’s a kind of a way of kind of, and that if that’s a person, an individual, just, you know, the pressure on them to get that word, seeing all this work, building up not being able to do it or responsible just for doing that packaging, and knowing it’s a complete pain, you know, is the mindfulness and the whole mental side. Yeah,
Jack McCardy 09:07
I think if you use like a real world example, I think an area that you see that most often like as a bottleneck, it’s something maybe like QA or testing, especially for quality assurance team is separate to the Salesforce team. And this is one of those things that when we talk about best practice, DevOps is not necessarily about the tools and technology, you can have the best tools and technology in the world. But ultimately, it comes down to people and how you manage people and that process of thinking about that, then, you know, your QA team, for example, don’t sit outside to Salesforce, bring those people that responsible into the team into the communications into the channels that they need to be in so that the whole team can be successful. And those bottlenecks don’t happen. The silos aren’t there. And that’s actually the probably the biggest challenge that we’re looking to solve, you know, for anybody that’s listening that’s slightly more well versed in DevOps or even does some of it themselves. You know, there’s tons of documentation or suggestions out there on version control branching strategies, or do you have
Francis Pindar (A2A) 10:03
branching at all? Is it trunk only? Is Bardsey versus Yeah.
Jack McCardy 10:08
Right. So all of that information is out there. So and still we see the required cultural shift being neglected as might be a strong word, but not as well considered or seen as less important. Yeah, showing the value of it. Yeah, exactly.
Francis Pindar (A2A) 10:22
And I think when we talk about backup in one of those zooms, and actually, for me, actually backup is a big cop can be a big cost saver as well. And so I’ve kind of used backups as well as a way of removing full sandboxes. Because I’ve got an environment that can could go into a partial backup, but obviously, limitations with that is only like 10,000 records per object. So it’s a pain in the ass to use. But the backup can restore to the maximum size of the partial sandbox. So actually, I could get rid of one of my full sandboxes, make a saving on that, get a backup, which cost less than that full backup full sandbox, and then see partial sandbox with backup data. So you’re testing the backup by seeding it in the first place by being able to restore to it and saving money on a full back full sandbox as well,
Jack McCardy 11:16
for sure that if we come back to one of the things that we’ve talked about is, you know, people’s mental health, I guess just having backup gives you that, you know, aside from what it’ll do for you, you know, your time to recover is one of the doora metrics, right? So if something does go wrong, how fast can you do that? And that absolutely is and we see it as part of your DevOps process, because that’s the team that’s going to be responsible for fixing it when it hits the fan. And it all looks bad on you ran that team. And they are exactly so we’ve actually started to see a little bit more of a shift or when we’re speaking to Salesforce teams, pulling back up out of IT ops or another team in the business and handing that responsibility back to the Salesforce team, which is great, because that Salesforce team needs to know what’s going on. And they need to know how to fix it. And they can’t just be given a chance give you
Francis Pindar (A2A) 12:05
abilities in other ways. So like one of the projects I’m working on at most got a lot of record based on thick, and actually just creating new sandboxes is just a pain because you’re essentially doing data migrations, to move conflict through. And also just creating a new sandbox is just a bit of a hassle. So actually, the backups great for that. It’s just, I’m just gonna restore those tables, for sure. Well, job done.
Jack McCardy 12:29
You make it sound like a click of a button.
Francis Pindar (A2A) 12:32
Yeah, well, I said, Yeah, it does kind of help you for certain things like that as well, which I found quite useful. So
Jack McCardy 12:38
yeah, for sure. For sure. It’s such an interesting space. And I think I think that shift in that understanding is definitely getting there. I think it’s interesting when we’re talking about backup most people or there’s a lot of people that would be like I use Version Control, I have a backup. And yeah, you do. But it’s a mess. It is a kind of, and you might not even have it all in there, which is also often the case.
Francis Pindar (A2A) 12:59
Go back to that. Profiles. Yeah, exactly. And I think if it is, it’s like, it’s a big topic. It’s a huge deal. And I think it’s also it’s quite hard, I always find it, it’s quite a hard sell initially, unless you’ve got the metrics and stuff to back it up to go, Hey, look, this is taking this amount of time it could be taking this if we just did you know, the so if somebody’s going into the what how do you see is that kind of like that progression? Through DevOps? Yeah. So
Jack McCardy 13:27
just to touch on metrics? Again, I think that’s one of the things that when we’re speaking to Salesforce teams, and, you know, how do you currently measure your success? Either they don’t, or they go, how stressed I am on a Friday, right? You know, there was a kind of the options. And I think that can be a real hindrance to them going to leadership, for example, and saying, hey, I want to buy this tool, or I want to do this, that or the other, and it’s probably going to take x amount of effort, and they go, what’s the return gonna be? And they go, I don’t know. So it’s metrics is something really important to consider, I think we see a lot more teams using the Dora metrics now, which is great. So that so looking at those things is absolutely a way that you can see your maturity rising. So there’s kind of two schools of thought on maturity, you can see that as the amount of the amount of tooling or the amount or the different types of things that you’re doing within your process. How much is automated or not automated, as this case may be, but if you look at a process, you can still have a manual process and maybe using a tool like gearset or, you know, one of the other DevOps platforms out there is we could automate it for you, but you’re still saving time by even still doing it manually, you know, so your maturity is rising, you know, is the level of effort to automate things going to be worth it? If you’re what’s the, there’s a bit of a balance,
Francis Pindar (A2A) 14:49
they kind of always come back to that constraints thing of actually, you could do it but if you’ve got another place that’s got a bigger constraint, then how’s it gonna help you?
Jack McCardy 14:56
That’s right. And I think a lot of the improvements that a lot of folks see when they first start down this road is once they start thinking about their deployments in the first place and getting the deployments but right, that time to value kind of comes down significantly from that one piece. And then it’s just, there’s just about the, I think they then find out, Oh, what if we, it’d be really good if we could do this, or that. And that’s when they will start to head down that path. And I think a lot of one of the pitfalls and common pitfalls that teams or managers can get sucked into is looking at utopia, looking at fully automated processes, and go, I want that, and have that as like the end goal, rather than, you know, appreciating that journey that you’re going on, because it’s like cliche, life is a journey, not a destination kind of thing. And, you know, the same thing can apply in this space.
Francis Pindar (A2A) 15:44
I think that’s the same for even if you look at it, as you know, the Salesforce maturity and stuff like that, you can see this whole utopian goal of chatbots, and all that other stuff. But actually, the end of it is progress, you are going on this journey, and you’ll find value in different things as you’re going through. And your worldview always changes as you’re doing it, you know, as you’re learning more,
Jack McCardy 16:03
for sure. I think DevOps is one of those things that it’s not you do this, and that’s the way you do it, it’s evolves and it changes. We do this right now. But always be looking ahead to say what’s our next thing is the way that we’re doing things now the right way, you know, always having kind of a bit of like a VA mindset, I guess about it, you know, it’s things fit for purposes, this requirement, what we needed to do, you know, always be thinking about, you know, what the next thing is for you and you as a team, and that in your DevOps process might mean, as we talked about version control, switching to a different git branching model, yes, things that you have a DevOps process set up, and it’s good, let’s assess what we need in the future.
Francis Pindar (A2A) 16:41
So even that could involve like, working with a company now that they’re getting a whole new team set up to support service cloud, for example. And if I, that could totally change the branching strategy of what you’re gonna go in. So it could
Jack McCardy 16:53
mentally new teams, I think there’s almost this notion that a couple of people are responsible for DevOps, you know, they look after the deployments or the tooling. And, and that’s kind of it, that’s their job. But introducing a new team and all members of your team, you know, it’s getting everybody bought into that, and understanding the part that they play and putting out actually putting responsibility in their hands to get their changes to the place that it needs to be for either the process to kick off or be responsible for that throughout delivery process will, it’s you know, it’s not just chucking work over the wall.
Francis Pindar (A2A) 17:23
Yeah. And that kind of understanding the, one of the things I presented earlier on was the whole, the mindset shift of what it is and people thinking, Oh, my God, you’re automating everything, oh, I’m out of a job. But it’s really not. It’s changing in the way you work. But then it’s more interesting. You’re not just doing the same thing again, and again, you’re actually working on the process and, and building it out and improving it and streamlining it. And there’s a great book that I love, called the Phoenix Project in its early I did Yeah. And it’s brilliant. It’s basically a storybook, essentially. Have you read it,
Jack McCardy 17:58
I haven’t read it. I am inspired, though. Yeah, it’s a
Francis Pindar (A2A) 18:01
cool, but it is basically a storybook on a company that is literally on its knees, I think I think literally first couple of slides saying their share prices crashed and the CEOs left or where all this kind of stuff going on. And the first 100 pages is just problem. And then it kind of shifts, and they start adopting agile and DevOps practices to really change the business around. And what I love about the book is you can spot the characters, the characters and books that are Yeah, that’s Jeff at work. And you could just see them everywhere. It really probably because it’s a story, but it’s very accessible people. So when I’m starting a new kind of DevOps journey, I start working on your company or not, there’s using using agile in a fragile way or whatever, you know, this is the book I get out and give to people because it is very accessible. And it’s just gives you an idea of the whole picture. I suppose.
Jack McCardy 18:57
The interesting thing about that mindset shift is I mentioned this in my talk earlier was those mindset shifts, and those cultural changes or routes, like role changes are can be a little fractious to begin with. And I think there’s a lot of notion these days that we shouldn’t be like, we want to please like our staff, you know, the we were speaking about it earlier, like speaking about it earlier, you know, the the talent is still scarce, it’s it’s in high demand, and there’s that, oh, we don’t want to change things because you know, they are bad, but it works. So maybe
Francis Pindar (A2A) 19:25
you know, they haven’t left. Yeah,
Jack McCardy 19:29
exactly. Right. And we don’t want to spoil the applecart. And you know, I think that’s again mentioned earlier, when it comes down to communication and say, Look, we understand this might be changes that you weren’t expecting, or might not wholly agree with, but want to buy into this vision that this is about all of us that if this is about giving you your time back, it’s not giving you some some happiness at work. And I think having that as an organization, if you have that level of maturity to look at yourselves like that and make a change and say yeah, we know this could cause this Using the short term, but the long term benefits are worth it. I think that’s a real way that you can set yourself up for success at the start of the process. If an employee leaves
right for the new world,
Jack McCardy 20:11
right, perfect.
Francis Pindar (A2A) 20:12
So yeah, that’s fascinate. Yeah, no, thanks so much. It’s been really fascinating. And yeah, I’ve learned a lot. DevOps has been quite good. Because I only really, from an architectural point of view, you’re kind of like, looking at it at this kind of high level. And actually, it’s been quite interesting just knowing how even just I’ve never even thought of the kind of the impact it has on people’s productivity and happiness side of things. I’ve always thought it’s just it’s a two lane problem that so it’s, you know, the both has been quite fascinating for me as
Jack McCardy 20:42
well. I’m glad picked up. Thanks for coming and, and inviting me on really appreciate it. Yeah. Cool. Thanks so much. Thank you.
Francis Pindar (A2A) 20:49
Thanks for watching, or listening to the Salesforce posse podcast now, please, please, please, if you like, or what you see or hear then please rate this podcast in your podcast player, as it tells me that there are people out there that actually are listening to this and that it’s useful to them. Also, it helps the podcast algorithms to kind of elevate the podcast in the different podcast directories which will be really helpful for me, as well. And finally, if you do have a question that you want to ask on the podcast, then head to Salesforce posse.com/message. And maybe you will appear in the next podcast, but apart from that, thanks for listening, and until next time, Ta ta.
One comment on “What is Salesforce DevOps?”