Panel discussion: The future of DevOps on Salesforce

Share with

Description

Join industry experts in this insightful panel discussion as we explore the future of DevOps on Salesforce. Hosted by Gearset, this video dives into emerging trends, best practices, and innovative solutions shaping the DevOps landscape.

Gain valuable perspectives from Sunny Matharu, Chief Technology Officer at ThirdEye Consulting; Jonny Harris, Salesforce DevOps Engineer at Zurich Insurance Ltd; Sami Hawkins, Business Systems QA Manager at West Shore Home; and Ben Laplanche, VP of Product at Gearset. Discover how to stay ahead in the ever-evolving Salesforce ecosystem, enhance your DevOps strategy, and drive your team’s success.

Learn more:

Relevant videos:

Transcript

My name is.

I am one of the associate product managers here at Gearset, and I'm really excited to introduce our panel session to you all.

We're going to be talking with some leaders today about the future of DevOps on Salesforce, and I'm really excited to, just introduce quickly, and then I'll let them introduce themselves, our four panelists today. We have Sanima Tharu, chief technology officer from Consulting. We have Johnny Harris, Salesforce DevOps engineer from Zurich Industries, Sammy Hawkins, business systems QA manager from Westshore Home, and our own Ben LaPlange, the VP of product here at Gearset. So, with that said, can I have my, panelists give a quick short introduction and just tell everyone about your kind of history with DevOps and, what you're here to do today? So, Sammy, you're first on my screen.

Would you like to go first?

Thank you, Claudia. Hi all. My name is Sunny.

And as we just heard, I'm the CTO of Consulting.

In in real terms, what does that mean? It means I'm a Salesforce architect that looks after all the enterprise and architect best practice for all of our engagements.

In terms of my relationship with DevOps, you know, I've been in Salesforce since twenty ten, but lots of other things like Java, Swift, Objective c before then. I've always been a developer at heart. DevOps along with data are two of my top three favorite topics. So I'm so excited to be talking about where we can take that in Salesforce.

Yeah. I've I've been on a journey already all the way from changes to where we are today. Excited to see what the future holds. Thank you.

Claudia, you're on mute when you ask for the next person, I think.

Apologies. Sammy, would you like to go next?

Sure. I'm Sammy Hawkins. Like she said, I'm the business systems QA manager over here at Westshore Home. We've been a Gearset customer for about two years now.

My own experience with Salesforce and Salesforce DevOps sort of started in twenty thirteen as a user and twenty sixteen as an I started out in a very strict org where we always had to follow, documented DevOps process of research and design and was it tested and everything like that.

So over the years, I've just been bringing my knowledge along and gathering what new knowledge I can for me to work that I that I interact with.

That's sick. And, Johnny, would you like to go next?

Yeah. Sure. So, yeah, Johnny Harris.

I'm the Salesforce DevOps engineer at Zurich Insurance.

I've been at Zurich now for five years, and I've kinda gone through the journey at Salesforce. I started as a very junior admin, worked my way through into developer developer for a couple of years, and then into the DevOps engineer role, We've quite a passion for DevOps, and I've worked quite closely with Gears over the last three years now we've been a customer. It's been a really good journey.

Amazing. And last but not least, Ben.

Hey, folks. Excited to meet you all. So, yeah, my my background over the last last ten years has always been very DevOps focused.

I've done a bit of a tour of duty working on kind of open source projects, platforms, and service.

Spent a lot of time with developers as users and both customers, which has been really insightful.

Spent a bit of time thinking about security and now really excited to be digging into the Salesforce ecosystem.

Fantastic.

Awesome. So I'm really excited to get started with our panel today for the future of DevOps on Salesforce. And my first question to all of our, storage panelists here is based on your experience and your expertise, what do you feel are the most critical areas of focus for the future of the use of DevOps on Salesforce? So it's open to everyone there.

I'm happy to jump in first. I'll take first. Yeah. First step.

I I think for me and especially on my team, I think the focus for us is is the right training, and development of the team.

I think the the DevOps space and especially Salesforce with AI coming through is changing at such a rate.

So making sure the team is kept up to date with the with the right technology, with the right expertise, can it then help us keep up to date with the customer demands and to make sure the right solution is used.

Because I found before if the right if the wrong solution is used or you start getting old technology used and it starts to get outdated, it can then start to impact actually, you know, increase your tech debt, increase it. You know, it starts to impact the whole release cycle then and your DevOps cycle starts to slowly just fall apart a little bit. So for me, one of the big things is definitely training, development, make sure the team keep up to date with the the best practice as it comes through because it seems to change quite rapidly at the moment.

Fantastic. And I see lots of nodding heads. And Sammy, Ben, Sunny, do you have anything to add? What would you like to or what do you feel is most critical to focus on for the future of DevOps for Salesforce?

Yeah. I'm happy to to chime in.

Don't mind if I say things are a little annoying. So I've I'm sure many people here have experienced the perception of DevOps being that it's all about deployment of metadata.

But DevOps is far broader than that. DevOps is about how you get something from being an idea in somebody's head all the way to being a change that's accepted by an end user.

And that's the top and tail that nobody really cares about. They care about or talk about and focus on the metadata deployment piece. They don't care about things like ensuring your test is still working. Your quality is still up to scratch.

Your field classification and labeling is still right. Your help text is still good because it appears to standards that you set out at the start in terms of tone of voice for your company. All the stuff around measuring the quality and correctness of your metadata and the adherence of it to your standards as business are just as important as getting, you know, some XML from Git deployed from source control into sandbox or or production. And I think that's where I want to see DevOps heading.

If if there's such a thing as an environment state for DevOps, that's why I see, something being an idea in someone's head. It's traceable all the way from know, whether it's Jira or Azure or something else that you track it in, being deployed, but also being quality controlled and managed across change program as well as it being metadata and treated as code.

Sorry. I was a little feel feel topical, but I I wanted to get it.

In, in that spirit, Sonny, of, getting ideas out of people's head and into production, I think you're right about deployment being at the heart of that story. And I think a lot about the adjacent tasks that people also need to complete. So things on my mind is always around how do we put an emphasis on code quality and security, for example. How do we help people think about kind of the appropriate testing strategies, and how do we help people understand whether the change that they're making is doing what they expected and that they can catch issues with it in production before their end users do?

These feel like natural evolutions of the deployment story to me, and I'm excited to see how we can kind of further that thinking, within DevOps in the Salesforce ecosystem.

So I guess I'd like to move on to my next one here. So I'd, again, like to open this up to everyone on the panel.

How have you felt the adoption of DevOps has helped you to overcome challenges or to plan for challenges you anticipate your organization may face in the future?

And what strategies have you implemented to address them and build resilience and plan for sustainable and scalable growth?

I could speak to this a little bit.

Especially coming from a team of declarative admins, a lot of the language around DevOps and the vocabulary that we use comes from a more traditional programming background. And it so it could be a little bit intimidating for people to adopt.

I think that starting with just the most simple structure that you can and continuing to iterate and add things to the process is really making it accessible for Salesforce admins. As it comes up, as it gets talked about more, at these summits and at Dreamforce, it's starting simple and building onto it and just getting that structure into place even if it's it's just okay. You know? Most people know we're not gonna work directly in production anymore. We're gonna start in a sandbox. But even something as simple as as that being an established process is starting to do DevOps.

So just having that structure and moving things through in a controlled way, and continuing to build on it is, I think, is what's working for us over here.

And just just to add to that as well, I think, actually, having that same mentality when you're dealing with the business as well, you know, these nontechnical people who don't wouldn't expect to understand DevOps. But they need to know a certain amount of it because you need to take them on the journey to better iterate and deploy iterate deploy. If the business isn't aligned to that, then you're gonna get stuck in the kind of mixed hybrid, agile world where, you know, you can iterate to a certain point, then you just have to block deploy stuff in.

I think there's definitely a win of the yes. The admins in the team, the declaratives. You might not understand the developer talk of it, but also taking that with the business.

What we've done before, we've had, like, a discovery session with the business themselves to talk about DevOps. Yeah. This is how we're gonna work. This is why we do it. These are the benefits.

They They definitely can work both ways from the technical guys and team and also the people who never look at the back end of Salesforce.

What what you're saying, Simon, Johnny, really resonates with me because I think when we talk about DevOps, the bit that we can often forget to kind of say out loud is ultimately we're enacting for the cultural and process change. So as you said, taking the business on the journey with you is gonna be key to your success.

And I think in my experience, when people are part of that process on all sides and they feel like they've been part of that journey and had a voice in it, then they get bought in.

Yeah. Totally agree. That's the experience we've had. When when you take them from the day one all the way through, it's just such a better success story from both sides.

Yeah. I definitely agree.

Fantastic.

And I suppose my follow on question to that, how do you feel the adoption of DevOps practices can shape the future of the product development life cycle? And what do you anticipate as the main benefits or potentially even challenges of scaling that over time?

Again, happy to go that. I I think that, especially like I said earlier, with with the business, if you can get them on board with the adoption of how it works, you can get to a point where you actually turn over, change at a much faster rate.

You build the trust over the course of a project, then out you exit the project, and suddenly you've got the trust there. They know how it works. You can start iterating through like you're just doing you know, I said BAU earlier. Someone said what's BAU?

So business as usual. You can start working at a faster rate. So suddenly, they're no longer waiting four or five months for work. You can give it to them in a week, and suddenly they're seeing their system change.

They're asking for something on a Monday. Friday, they're getting the change deployed.

And they start to see what actually you know, they're asking to change where does that money go? Oh, here it is. We're seeing it instantly. It's not just going into the ether of a company and change is being done at some point. They're seeing it at a quicker rate.

Totally agree. And I think that leads on to our next topic around kind of speed and efficiency.

How do you feel that automation platforms, which are more tailored for Salesforce, can improve efficiency and reduce time to market for new features and products? And what impact does that have on what the business sees?

I think from my perspective, there's a bit of a theme that's already been talked about certainly from Johnny in that if you're working small and delivering frequently, then you can show that value to the business. And then if you're working with a platform that can support you in those needs, then you can really focus on the business value side of it because you can trust that platform's taking care of the deployment, enabling you to do the test thing, get all of the feedback loops and everything, that you need in place.

So you can kind of trust that the automation is doing doing this thing for you, and you can you can work with your team.

And and also just on that as well, if if it's the right use of automation, you can start to actually take time away from using these tools. You trust it's gonna work. You trust how quick it's gonna, you know, do a deployment. You haven't then got devs sat there watching, as Jack mentioned earlier, the the circle spin round and you're watching unit test to make sure they don't randomly fail at some point.

You can trust it. You trust your automation. Devs can just palm off the work. Well, I've done that bit.

It's ready to go. It's tested. It's gonna be deployed. I'll work on the next user story.

The business there again start to see their value for money, right, the value for change of what they're asking for. They come through just at that quicker rate.

I, I hope as well that as we continue to build trust with the business that more changes will get pushed towards kind of the Salesforce platform and that they can see the potential and how that can help them as well. So what may grow from a single project maybe continues to kind of snowball over time as well as we build that confidence and and we win credibility.

Yeah. To that point, I think it ties in really nicely with the point Sunny was making earlier as well about it becoming more accessible in the Salesforce space. You don't have to spend time learning how to code and learning Git and everything.

You have these tools that are specific to Salesforce that are gonna make it easier to expand across all different businesses, not just the ones that are doing really complex coding work.

And just the one you know, not have to look and try and work out CMD command, you know, work with command lines as someone who's added an admin. That's about, you know, one of my experiences come joining as an admin and building through and suddenly being palm, you know, given the task of doing deployments with a and migration and CMD tool. Yeah. Suddenly, it's like, oh my god. I can't do the wrong thing. That is catastrophic. So, yeah, it definitely starts to build that kind of, again, the trust and confidence as you're doing the work and change the business.

Absolutely. And, Sami, actually, you might be quite well placed to answer this next question, which is, in the future, how can organizations look to balance the need for rapid deployments with testing and quality assurance that is required, of course, by the end users of this development work.

Yes. That's something that we've definitely been working on on our org, especially since we're on continuous daily release cycle.

So we're pushing changes out very rapidly, and we have to find that balance of ensuring that we're promoting quality work, but also keeping up with the stakeholder demands because they have a lot of really good ideas that they wanna see right away. So we've found that balance, I think, so far by defining a line for what needs additional testing. For example, we do a much more thorough review on automation changes than we would on, say, a new field coming into the system. Not that a new field doesn't come with risks. We may ask questions about whether it's a required field or if it's gonna be involved in a validation rule and things like that.

But I think it starts there with defining some standards, not trying to go all in on everything at once. And then we've also been starting to leverage some automated testing tools, and I think that's also gonna become really big in the future in the DevOps space.

There's still a little bit of barrier to entry to that because it gets a little more codey as you get into the automated testing solutions out there, But I'm excited to see them become more tailored towards Salesforce like we've seen with Gear Set and Deployments as well.

Yeah. Absolutely. And, for our other panelists as well, what are your experiences prioritizing that kind of speed of delivery over the, quality assurance that is, of course, just a key part of the development life cycle?

Why do you have to choose one over the other, I guess, is the point. Like, we said, if you if you're if you're at the state or stage where you can automate away a lot of your regression, and all you're really doing is testing the thing you just built using tools, I don't know, Selenium or Probar or whatever else is out there.

If you're able to automate away a a a ton perhaps of legacy build, you know, perhaps on experience cloud for your your customers, internally for your sales teams, for your customer service teams, etcetera, and that's all running automatically on a server triggered perhaps by a DevOps job in git or gear set, then why can't you also do that while releasing quickly? And then you're not sacrificing anything, really. That the problem you've got is that barrier to entry that Sandy mentioned is there's either a cost barrier because you gotta pay for these tools.

There's a spike in spend on CapEx to stand these tools up and build out these automated tests. And then you've got to think about what happens to your UI test automations as your solution evolves. You know, your UI test should rightfully break when your UI changes.

But then if it does, it requires something to go back and remedy or rectify or update those UI test. And that's good practice, but it comes with either internal administrative overhead or external consultancy overhead. And that's the balance that really needs to be struck. It comes down to money, I guess, at the end of the day.

It's all business in the end, isn't it?

Fantastic. Yes. I totally agree with you. That's definitely the the future that we want to look towards for our DevOps.

And then I think then I'd like to ask you all of about something that's probably quite a broad topic, which is, what are the strategies and best practices that an organization should be keeping in mind if they're moving from a place of being very low code and they want to start adopting version control, testing, monitoring, greater security measures in the future as part of their move towards scaling and putting in some sustainable growth for their DevOps practices?

I would say you wanna start by being really clear on, like, what it is you're trying to introduce and why. So I make sure everybody understands kind of the value and the benefits again. Then think about how you can the DevOps principles, I guess, are coming out and across all of our answers are, like, start small and it's alright.

If you really have a home that values people, make sure they understand why the thing is gonna be valuable to them and how it's gonna help them. Then I mean, that's gonna be a good bedrock if any kind of rollout strategy.

Yeah. And just on that as well, as I mentioned right at the start of the panel for me, is a training. Right? You can't get enough training with the once you get the understanding of why and then how it works, you've got a good basis to actually then step on and start to iterate and improve as you go through. So definitely one of the things is make sure that at least one person or a team of people are well trained on what you're trying to achieve.

So you can have a, yeah, a good foundation to work from rather just everyone trying to work out for themselves, pulling in different directions.

We'll try and just have, you know, one goal, one, you know, train them all up, and then you've got a good place to start.

I'm, I'm curious, Johnny, if you have any success with things like train the trainers or maybe kinda like evangelists in the team that kind of rotate around.

Not rotate.

The evangelist is me and the team.

But I've done over the last six months, a lot of training in the team to try and get us moving forward. And for me, I spent I did a two year DevOps apprenticeship, ended last year or the year before. And it and it where I've been working in a DevOps team for five years, I had the how we do stuff. Fine.

I get it. But, actually, what the training allowed me to get, which really, really helped is to why we do stuff. And why do we do it in a certain way? Actually, what does that achieve?

How does that give us the best practice? What does that look like in the long run?

Yeah. I that's why I always try and push training for people because it is really, really strong and powerful.

It sounds like the the first principles thinking kinda really stuck with you there.

Yeah. Yeah. Definitely. I love that.

We, we have a grad scheme, and our grads are really good on clients because we don't get them anywhere in their client until we get them foundational knowledge.

Because that foundational knowledge is what underpins the best practice and the good practice when you're out in the wild doing things in real life. So we spend a lot of time providing that in a closed environment, a safe environment where it's okay to fail and break things so that you can try things out, so that you can speak to either myself or architects in our team that can teach you and guide you and tell you what has gone wrong when we've done things in the past for clients, and what has gone right. And that that training piece can't be overlooked. You mentioned it at the start, I think, in your first the answer to your first question, Johnny, as well. Like, training is so important.

Yeah.

Yeah, very close to my heart.

Yeah. I think we're looking at going through that change very soon on my team, as we've both been using the UI and gear set to do compare and deploy.

Pipelines is coming up in a lot of conversations for the future.

We're gonna have to get over that hurdle, get over our fears of version control. And as I'm beginning to think about that, I'm doing my best, to when I think about the training that Johnny mentioned, I'm trying to think of it in terms of building on concepts they're already familiar with. When I think about a branching strategy, I think about pulling up a picture of our Salesforce orgs. And because it's very similar to how we're doing things now, we're just gonna let it run through the command line. So, just relating it to existing concepts and building on those, I think, can help with the transition.

Fantastic answers.

Which brings me to my last, which is, a very trendy topic, which is how might emerging for Salesforce in the future. So AI, everyone's favorite topic as of late.

But I'm sure everyone has, you know, their own framework like a reference and their own opinion on this. So I'd love to hear from our panelists how you feel that it might influence Salesforce, DevOps, and development in the future.

Happy to go or Fanny if you wanted to go.

I I I was gonna say, I don't know, but I'd love the I'd love it if I got to a place where I didn't need to do boilerplate stuff every time I started a project because you could do it using natural language and AI. If you could take care of the complex parts of your project because you've got pain in the RCBQ deployment today or a very complex sharing model to deploy, because of GDPR and things we talked about in my backup and archiving panel session. If you could focus on that, the hard stuff, and let AI or automation take care of the the boilerplate, yeah, that'd be a really good place to start.

Yeah. Well, I was gonna say, especially for for me, the the kind of challenges I see coming from it, especially around low code and no code using these u UI tooling, especially now stuff like flow that is actually introducing coming away from Apex. You know, use a nice pretty flow, is actually you have the risk and the people losing understanding of what's going on in the background. You lose the understanding of metadata. How does the metadata how should it be structured?

And, actually, what that can lead to is with that lack of knowledge, if something goes wrong, you lose that of how do you fix it. If you understand the message, normally, you can work out what's going wrong in the back end and try and fix something. But with people using more and more UI, you lose that in-depth knowledge. And, you know, it's great that, you know, gear set shows, like, the UI comparison of the flow or the I mean, there's another UI bit coming through for layouts. That's great. And it's great to help admins boost stuff through, but you you need people in the team who understand how that looks in the background, what should it be, and if it goes wrong, how do you fix that? So it's not just, oh, I can only deal with UI, and if it breaks, I'll I'll step away.

Yeah. I'm I'm excited to see how AI could maybe underpin making some of this stuff more accessible and helping people educate and get ramped up on some of these concepts as well, whether that's kind of understanding what's going on behind the scenes or flows or making something like metadata and Apex kind of, more accessible to folks as well and look a bit less technically overwhelming.

I mean, there's a lot of folks in this ecosystem who wanna do great work. I mean, the more we can do to help them on board and get up to speed and explain what's happening, I think that's, that's gonna be a win for everybody.

And I think we're hearing there some really common themes that we've heard before actually throughout about accessibility, automating away what can be automated.

So it'd be really interesting to see how those things are applied across.

And with that, I want to say thank you all to our panelists.

And we actually have five minutes for a q and a if you'll have to answer a few questions. And, actually, we have had a question come in, from Dylan, which I think is aimed at you, Sammy, which is what was the biggest hurdle getting to continuous daily deployments?

Oh, gosh.

Oh, my Oh, Sunny.

Is it Sammy or Sunny?

I don't know.

Sammy, I think. Although, Sunny, if you've been doing continuous daily deployments as well, I think that you should also pitch in.

I'd rather shirk that and let Sammy do.

Actually, that was kind of how we were already operating in Jira without, the the guidance of Gear Set. We were pretty much releasing things as quickly as we could, which meant that sometimes changes were going out the same day. And for more complex projects, they may take a little bit longer.

But the benefit that came in when we introduced gear set is that we stopped stepping on each other's toes because now there's a queue. Everything's going through in a controlled way.

But, yeah, for us, there wasn't too much of a barrier to adopting continuous and and continuous release because it's what we were doing without the tools in place already.

And from our other panelists as well, do you have any kind of perspective on what you feel could be hurdles to kind of getting to that constant or near constant release cycle?

Yeah. For for for myself in insurance industry, it's the compliance. It's the like I said earlier, it's the stuff around the red tape, which makes it slightly slower to get to production. Now I'd love to get to daily deployment.

So I think it's good going. If you can do that and it's a good achievement, but, yeah, I think sometimes compliance can step in the way of that and just hard stop you. Right? You need the right sign off, the right testing, the right time to deploy.

Yeah, for me, it's the compliance is the hurdle.

Amazing.

And oh, so we have one more question. Is there an emphasis anywhere in DevOps towards product development management in terms of backlog of requests?

I think I can always answer this one, to a certain extent.

But I'd like to give it to our panelists.

Is there any emphasis do you feel in DevOps towards, the kind of backlog of request, the kind of product management, aspect of things?

I'm not sure DevOps is the the main point around backlog management or or the things that am I interpreting this correctly in terms of how what are you focusing on when you're prioritizing what to go live with next? Right? Is it the backlog of issues, complaints? Is it, desires to enhance the product or whatever else it might be?

If it's broadly well understood by me there, then it's not really to do with DevOps at that point. It's to do with your product management. You know? Yeah.

Of your org set up to make the right decisions for the wellness of the platform as a whole rather than being reactive to noisy business stakeholders because we have plenty of them and that people got a day job and it's rubbish when things don't work as they they want it to. Equally, the job of good and strong product owners is to protect the product and the platform from that such that they can triage and focus on the right complaints at the right time. You know, when some things have gone really badly and you're not making money as a business, yes. Address it Equally, always focus on the product rather as a whole and consider that when you're thinking about what to do with the DevOps.

I might have not understood that question probably today.

I I think that was a I think that was a perfect answer. And, hopefully, Dylan, that has answered your question as well.

On that fantastic note about the kind of broader platform, that's represented by the teams that we work with, I'd just like to ask whether any of our fantastic panelists have anything they'd like to close out on, to end our panel today on the future of DevOps.

It's fine if you don't. With that said then, thank you very much to all of our fantastic panelists. Thank you everyone as well in the audience who's taken part in the summit today, and please have a fantastic rest of of the week. Thank you all for coming today, and I hope you have a wonderful rest of the day.