Description
Catch up on this discussion with a highly accomplished DevOps Panel from the Gearset DevOps Summit 2021, as they discuss the key insights into how to build a high performing release team for Salesforce. Ian Gotts (Founder and CEO, Elements.cloud) is joined by Roberto Drumond Da Silva (Senior Technical Architect, Salesforce), Jan van Os (Senior Solution Architect, Salesforce), Greg Grinberg (Senior Director, SilverlineCRM), and Sam Arnold (Account Marketing Manager, Gearset).
Learn more:
Transcript
So next up, we've got our DevOps panel. So I'd like to welcome back Ian Gotts.
And on the panel, we've got Roberto Drummond Da Silva, Jan Vanos, Greg Grinberg, and Sam Arnold.
Take it away, Ian. Loving the shirt, by the way.
Thank you very much.
We always try and make sure we have, something bright and, to brighten up the day. So, thank you very much for all of you who've been listening. This is, a great panel session, I think, to finish the day. We started today with, talking about return on investment for DevOps.
And, Kevin and I in the keynote talked about the maturity curve. And I think the question for many people out there is that this is fantastic, but where where do I start? How do I build a business case? I can see the benefits, but I now need to somehow build a case for for my senior management to understand why we need to go and do this.
So we've assembled a a panel here with years and years of experience around DevOps and Salesforce. I'll just introduce them, and then let's launch into some of the questions. So I've got a set of questions I want to ask, but I'm sure that you as an audience want to ask them as well. So post those in the chat, and we'll have some time at the end to pick up some of those questions.
So first of all, let's, introduce the panel. If I walk walk around the panel. First of all, Roberto Drummond da Silva, a technical a senior technical architect at Salesforce, originally from Venezuela. In fact, fantastic place. I went there on my honeymoon many years ago, but he's now based in Amsterdam. He joined Salesforce in two thousand sixteen and is now part of the professional services team that focuses on strategic clients. But he's also been responsible for building the internal best practices around DevOps and also, for Gearset.
His colleague, from Salesforce is Jan Vanoss, who's a senior solution architect. Again, works alongside Roberto in that same team. He joined Salesforce in two thousand and nineteen, but actually brings us a really interesting mix of, of experience because before that, he was the platform owner at a client. And before that, he was a consultant. So he's seen the really different aspects of what it's like dealing with Salesforce.
We have Greg Grinberg who is a senior director. He's been twelve years at Silverline CRM. And And if you've not heard of them, that's surprising because they're a platinum Salesforce systems integration partner. He's there as a senior technical architect, so he spends a lot of his time advising clients on DevOps and their DevOps strategy.
And then we have Sam Arnold, who's the account marketing manager for Gearset. She's based in the UK, but she talks to hundreds of customers. So she hears where they are on their DevOps journey and what's going on. And and bear in mind, every journey is different. And again, for the people out there listening, you may be in different positions in that journey and that level of maturity. And hopefully, the panel session will start to put that, give you some, some useful input into where you are on the journey, where to go next, and how to build build up that, that story, particularly when you're trying to get investment for for moving forward.
So let let's start off. Roberto, so you see lots and lots of different customers. What what level of maturity do you see DevOps? Clearly, DevOps is this this new growing trend, but it doesn't mean everybody is there. So what's the level of maturity that you see?
Yes. Thanks for the question. Good morning, everybody, and good evening for the ones in Europe.
Yes. So, across, yes, my experience with Salesforce, I've seen all kinds of variety of maturity levels. So you come to smaller customers, which, will have a very small team of admins, and they will, be using, change sets for deploying their changes. So they don't have a real high cadence of changes in their self self self force implementations.
So they, yes, they pretty much use, do small changes maybe on the UI, add a field here and there. So those are what I would call, like, lower level of maturity.
Then you you get to, for example, customers that, like, big global customers, of course, where they have a very, mature, COE, defined, so a center of excellence where they, define so, typically, I've seen in, kind of regional orgs. So we are talking about multiple Salesforce orgs that are integrated maybe to give an overview of different zones. For example, Europe, the Americas, Latin America, etcetera, Australia, you name it. And they will, yes, they will definitely have, some they have already, have defined some tools for doing dev DevOps. So, typically, you will have dev DevOps tools using in this kind of customers.
So they piggyback. So they they've already done the selection process. They, they they go to gear set and other providers, and they select.
So these customers, are quite clear. So recently, for example, in one of the customers, they have a very, clear strategy on DevOps. They had a new production org. They knew exactly what the process is.
They have it documented. They have, for example, in the in kind of wiki style that you see quite a lot in in in customers. So they they have their, every step of the way is documented. And then, of course, you have the things in the middle.
You have a smaller teams that want to go from very small and start being a little bit more productive, having, agile sprints, to be able to very frequently, do increments on their products with a product owner, etcetera.
Fantastic. So I think the important message there is if you're thinking about DevOps, you're not on the bleeding edge. This is this there are we can look to example companies out there who are doing a great job. So so, Sam, why do you why do you think that DevOps is suddenly or seems only to be gathering momentum now? It's clearly it's been around for a while.
Yeah. So I think just to build on what Roberto was saying as well, when we were, looking at the results from the state of DevOps survey, we really saw that a lot of people are, getting up to speed with version control and really getting on with the sort of get part of the the DevOps strategy. But actually automation is next on on people's road map. So what we're seeing is likely that a lot of these sort of Salesforce DevOps teams will be moving towards automation as we go into twenty twenty two.
Why now is a really great question, and I think that, you know, DevOps as a concept has obviously been around for some time, and it's arisen from, much more technical, platforms, more traditional platforms.
But the philosophy philosophy behind it is really aligned with the Salesforce philosophy. It's ultimately about, empowering, you know, the team to own that whole process, right through to the IT infrastructure, which, you know, very much marries up with Salesforce's, own philosophy of clicks not code and having people as, brought into the philosophy as possible. Of course, that sort of falls down a little bit when you're looking at the execution because DevOps is very traditionally very technical, and you might have an entire team focused on managing that. So I think now as Salesforce is getting much more complex, and we've heard earlier today, that, you know, Salesforce orgs are getting more complex, the needs are getting more complex as we support more business units. We're getting to the stage where actually developers and more technical teams are coming together and things like the Salesforce, DX being released.
This explosion of complexity, I think, is pushing down this road of DevOps. And, of course, now Salesforce themselves are putting much more weight behind it. It's on the agenda. It's being educated on within Trailhead. It's being talked about much more, and the introduction of the DevOps center will obviously continue to, increase the appetite of it. So I think that on top of the fact that we've now got tools that are filling the gaps, that are allowing people that are across multiple different skill sets to be able to join in with what DevOps is and be part of that process, is a big reason why now is the time for DevOps and Salesforce.
And we also we also shouldn't forget that the last eighteen months we've almost been sitting at home, excuse me, on the bit the level of digital transformation. The the the business is now saying deliver stuff faster, deliver stuff more reliably, and it's dramatic changes. I think there's a there's another aspect there that's that's coming from the business, and therefore, IT is trying having to keep up. So, Greg, as as a consultant, is it, like, is is there DevOps in a box? Is it is it you, the consultants, who have been asked, like, please give me DevOps, or is it being different from the client? How does that work?
Yeah. It's a it's a bit of a mix, and I would say there's really three profiles of clients I see most commonly.
You know, number one is an organization has a strong DevOps culture in other technology stacks, but they're just getting started with Salesforce. You know, maybe they're Java, maybe they're dot net, what have you. And those teams, coming from traditional technologies stacks, usually are not familiar with some of the unique challenges, that you have with DevOps on Salesforce. And that's where, you know, they know they want DevOps, and it's just a question of, you know, how do we get there and what do we need to be thinking about that's specific for Salesforce, right, and where tools like yours that can help bridge a lot of that gap.
You know, the other profile of customers really, folks who have a greenfield Salesforce work, maybe they don't have, you know, DevOps for other technology stacks, but but this is an enterprise or business critical, you know, Salesforce work, and where it's really it's really being driven by us as consultants of, you know, here's the value of DevOps. You know, here's the cost of a production outage. Here's, you know, the value you're gonna get as a business of time to market. You know, this is why you need these processes and tools and enablement into place.
And then the last, but, you know, which I would say is probably the least common is, clients where we come in where they really already have a mature DevOps process on Salesforce. You know, I see it more and more, I would say in the last few years, but it's still pretty uncommon for me to come into a Salesforce work that has source control, that has continuous integration, that has, you know, a complete software development life cycle kind of built out and defined, and running on all cylinders.
And and may That's So That I'm sorry.
Go on. Yeah.
Yeah. I don't but maybe to add, to Greg's point, often like these customers that that made a big choice to do their transformation with Salesforce, they already had to consider a lot of things, and not all of them thought about, well, that DevOps stuff, right, that we bring up. And then it's it's often indeed the consultants that say, okay, that we think about how are we actually going to deliver that business value?
And and that's sometimes a challenge what Greg said to, to explain. Like, okay. Sure. You've got the Salesforce licenses now, but now we need to implement it. And we don't only need, manual screwdrivers. We need, power tools to to do hard job.
So so when where do we start then? I mean, what we talked about the maturity curve, but, earlier in the keynote. And, again, I I know that was recorded, and people can go back and refer to it. But where are the quick wins? I mean, it's great. I need a DevOps strategy, but sometimes I need some quick wins out there to try and get kinda proof to management that this is making a difference. So where should I focus?
Yeah. I can Go ahead, Jen. Yeah.
Sorry. The typical online meeting thing. Oh, you you go. You go. But, I think it depends, where you are in the journey.
So are you a consultant starting in a new greenfield implementation, Or maybe you're listening to this panel and and you're an admin and you've inherited a nine year old org that is, running not not that nicely. But I think for both counts that that you need to get DevOps on the agenda as quick as possible. Start explaining what it is and and why you do it, what the advantages are. And then out of that, you pick the tooling.
Right? The tool the tooling is not the goal. And I guess for the existing admin or an existing org, it might be a bit more work, but I think it's easier because you already have felt like, the company already felt a lot of pain by not having, DevOps. They already felt the pain of, okay, we're going live on the the twentieth of May, and all of a sudden, it's like, oh, we can get these chainsets to work, or we are releasing stuff in this org that we that we weren't expecting.
So it's easier to build a case, I think, for for that particular scenario. As you can explain, okay. This is what we'll get.
So I get so I guess an an early win would be to just get an approval for a POC, talk to a salesperson from Kearset, or any other. So that you're interesting. Right? And then just start playing with it and show the value of it, and and make a business case on a on a small paper napkin. Doesn't have to be complex. I think if you can show the value, then that's the biggest win.
I would second that. I mean, for existing Salesforce works, right, the value proposition is sometimes so stark and clear that, you know, all our team is spending five hours a week, you know, doing deployments or remediating production issues or, you know, every time we do it, the production deployment is an all hands on deck situation, you know, and and we've lost, business, user value because of the x y z. Right? Sometimes for existing works that that value proposition is so stark, you can make the argument pretty easily of, you know, let's start somewhere. Let's start with something simple. Maybe it doesn't fix all our problems, but it's gonna help us get out of the hole.
But some of this is about defining the the DevOps process. I mean, if you just stick some tooling on top on top of a broken process, then we're just doing do we're just doing the wrong stuff faster. So there there there also needs to be, I mean, a bit of a chance to look back and go, okay. How do we streamline this? So, I mean, how much of that, Roberto, are you spending time at helping customers understand what the DevOps process should look like?
Yep. It it it of course, it all depends on the maturity. Right? For example, in the customer where I where I am now, none of the developers get access to any of the sandboxes, which is not the development environment.
So it's quite highly in, in in a mature. They actually use skill setter, by the way. And they, yes. So you the it's it's quite easy for any person in the team, like, a scripted developer or or an admin, to be able to integrate and to do their changes, and then all the quality gates will be will be there.
So for example, just to give example, so, if you if you configured, any any change in Salesforce, you do a field that you maybe change some code, you can already know very early in the process if you'll have if you are breaking your test classes. For example, if you make that field required, you will already know that very early in the process. You can see, how if you're adding code, what is the test coverage that you have. Are you, you can also require I, we can only commit changes whenever there is a eighty five percent code coverage.
So you are already from the very beginning catching. And, also, you can ensure that your change is deployable. Right? And everything that before actually it gets to the next environment.
And then another thing also which, I find very useful is that these kind of tools kind of force you and also with version control to have, a peer review process. So you also are in are increasing on the quality of the product that you are creating because then you, you you propose your code. So when a review a reviewer a a bit of yourself so if if you have two admins or two developers, they can be checking each other works. They can already see, for example, with status code analyzer, oh, there are some suggestion in your code.
Have you already looked at them?
What about this? There's a security issue here. Have you take take that into account? So, it it really helps you to go to work in a process. Like, if we saw earlier in the presentation, in the summit, what, Matt was showing, you have this, structured process, and it really helps you to, to everybody work on the same way using the same tools, what, Sam was referring earlier.
And if I could just tell, I think, the one thing that's really not been mentioned that I think is a really quick win that can set people up really well is version control. It's the start of the spectrum. It's a great way of just starting that journey, And that will start that process of just making a level playing field and having that audit trail, having that one source of truth, which really should be the priority when you're starting on this journey.
But if I if I listen to Roberto, do the the question is always that do I need DevOps tools or can I can I just do this manually? I mean, Greg, if you walk into a client, they go, actually, we don't want to use any tools to to just use what's out of the box in Salesforce. What's your what's your reaction to that? Or how do you how do you persuade them that's not necessarily the right answer? Right. You're taking out desperate to get in as well.
So Right.
And, I mean, the the challenge with, you know, what's out of the box with Salesforce is they don't give you a complete solution. Right? They they give you building blocks with SFDX and the investments they've made in tooling and the command line there, but those are just building blocks. Right? And in particular, Salesforce has really focused quite heavily on the developer experience, when we talk about, you know, the nuts and bolts of deployments and things like that. And they've given less love lately to the admin experience. You know, if you're an admin and you don't have any kind of tooling around the standard Salesforce tooling, you're probably still using Change Stats, which have been around for, you know, well over a decade now.
And trying to build something on top of SFDX while possible is, you know, a significant and ongoing investment that you're making in keeping up to date with the Salesforce metadata API and new Salesforce releases with, you know, bringing a good UI UX to your citizen admins and kind of power business users who are maybe just doing little things like list views and reports and stuff like that. And it's a pretty big investment for a company to take on. And I I would say there needs to be a really compelling reason why you're going down the build route on this DevOps tool rather than just buying something that's, you know, works off the shelf and is used by tons and tons of companies.
Yeah. And and I I guess also the question, not even built, but just not use any tools. Right? So and that's that's changed. I I can only emphasize what the the whole chat is saying, Ricardo, Bill, I would run.
I I've been in this situation before as well where our customer said, yeah, but we just already spent this amount on licenses, so we just want you to do it. And it just needs more explanation on on why you actually need the tools. I've never built a house myself, but I can imagine if you buy a house, you're not gonna tell the constructor that, oh, don't use any tools. Do it manually.
Well, Well, the constructor is probably also not gonna say, sure thing. I'll do it anyway. Right? We just need the tools to do our job properly, and that sometimes takes some extra slides and convincing.
Yeah.
I think that that house analogy is really good. It's the same for architecture, which is but build me a house, but and I'm not gonna tell you how many floors it's got, but please architect it.
And then at which point you go, well, I built one floor a house with only one floor, and they go, where are the stairs gonna go?
It's like, well, you didn't tell me about any other floors, so we didn't have any stairs. So and it that analogy, I think, works really well, which is yeah. If you're gonna build a house which is strategic long term, something which is important, then you need to invest in the tooling and invest invest early to make sure that, you that the longer you leave it before you start putting the right tooling in place, the harder it's gonna be to go and put it in place.
Yeah. Yeah. There is one guy on on YouTube that actually builds houses by hand. I don't know the name of it, but it's really interesting. He builds everything with mud and with his hands. So that's the only exception. Right?
But, other than that And and if I can add a little bit on that, I I think, in the end, if you need these tools, it's this is a a matter of choice.
So I've been in customers that they, they want to build, like, they have, like Greg was saying earlier, a lot of experience building software in, in their IT departments, and they have already a version control, and they have already DevOps, integrated. And and then they connect with the SFDX, and and and for them, it works fantastic. So they have in their organizations, they have, a dev org dev org, engineers, which will create all the scripts and will get into the ins and out of the metadata API, which is also another thing that some of the customers says, well, I don't want to spend time, with the resources I have, to follow-up three times a year all the metadata changes that are the dependencies to make sure that I every time that something changes, something is failing.
So, that's why I think these tools help you to to go over it. So you are above, and you also get additional tooling. For example, you can do, what was mentioned earlier, you you can do comparison of org. So if you see an issue, it's not working in an org, it's working in an org, in your dev, but not in your QA.
You can very easily do an org comparison. So these are tools that, are mounted on top of the metadata API that help you to, you know, save time in the end because that's what we are doing here is saving time. You can also monitor the data day metadata. So for example, you can integrate every time that anybody is developing something.
You will get a message in your Slack group. So you have a specific Slack group for DevOps. So you can see, so if you're a product owner, you can see what are all the changes that are happening.
And this is all done with automation. So you see, oh, this user story, I can see that it has been promoted because it's already, there's an automation job that has been kicked in.
And, also, you can, yes, monitor your test classes. So there's all kinds of functionality. You you have a central place to see all the deployments that you have done. So what has changed? So if everybody's using the same tool, you can see these are all the changes that has have happened. So if something stops working, you can really easily follow-up and see what metadata has been changed. So, yeah, it really depends on on on on what you as a customer want to do.
So I I I mean, I think the the summary here is that, yes, you need DevOps. No. You can't do it on your own. You need some DevOps tools.
And I think we need to try and convince development teams that they should be spending time developing Salesforce and the value for the cuss for their their end customers rather than trying to build DevOps tools themselves. Oh, they could do it, but the question is, if you think you can do it as a as a spare time or as a hobby, you gotta look at why why is there a marketplace of DevOps tools there with teams of developers, and do you really want to be doing that? So can I just change tack very slightly and think about we've talked a lot about the technology, but we haven't spent very much time talking about the people?
So I mean, I don't know.
Greg and then Sam, can we think about is this just a technology issue, or or how much of this is about changing the hearts and minds of the development teams?
Yeah. And I would say people well, I I would say, first of all, DevOps absolutely encompasses people's process and tools. Right? If you have one without the other, it's not gonna work very well.
And on the people side of the equation, there there's some unique aspects to Salesforce in particular because you have your traditional kind of Apex Lightning developers. You know, they wanna use Git. They wanna live in their ID. Right?
But you also have admins who are more commonly working and living under the setup menu.
You know, you may be used to using change sets, and you really have to bring those two groups together into one process and get everyone on board with the same kind of process and workflow to have a complete solution. Because if you you can't have, you know, half of your sales were sort of being deployed one way and half another way.
And, you know, this is in my experience, what this what this usually involves is some training and enablement of the declarative side of the house. Right? Getting them into the mindset of, you know, here's the benefits of version control. Here's all the cool things you can do.
Like, you can roll back on Salesforce, which isn't something that you can do on Salesforce by default. You know? Here's the value of having your work under version control. And then for the devs, you know, kind of bringing them in as as a support team for, you know, helping with tricky metadata XML issues, you know, making sure that when they write a trigger, they're also thinking about, you know, what are the process builders or flows on this object.
And it kinda touches eventually the architecture of the Salesforce work and making sure that, you know, these two teams who might be more used to working a little independently and kinda doing their own thing or kind of more a cohesive, you know, team that's just solving things whether it's declarative or custom.
So, Sam, is there stuff that that I could point to in Gearset to help people build that education?
Yeah. Absolutely. So, I mean, tools like Gearset are built so that it can be done declaratively so that it's not quite as daunting as it first sounds for somebody who is used to doing, clicks on code working off the menu as as Greg said.
But, you know, in terms of education, there's things like the DevOps launchpad that we've got in place. The trail, the Trailhead has got loads of really helpful DevOps resources as well if you want to go back to basics and learn those things.
But I definitely agree. Like, it's there's two parts to bringing people on board. That's the education side, which, you know, we can also come in as a team and provide training and, one to one education with your team to to show them where the benefits are. And there's also the the buy in early on is super important. I think before you even go and choose a tool, actually get people on board with the concept of why it's a really good thing for your company, and then get them on board with choosing the tool. Get them on board on what do they look for, what's gonna be useful for them so that both sides of the coin, the devs, and the admins will be happy with the tool that ultimately, you both end up using.
Maybe Sorry. Yeah. So one thing to add, I think learning, enabling is very important, but, the thing that really helps well is that you get buy in from management, senior management to spend time, like, on a continuous basis. So teams that have the time available, so they've got blocked out user story points, which they can just spend on learning, actually spend time to talk to each other and discuss things that you find out.
Because with, well, I guess, two, three releases a day, with gear set, there's there's so many new functionality, and it's easily that you that you don't catch up because you're just in the flow of releasing and you're happy with what's there. But one person might notice, hey. There's this new feature, and let's use it immediately. Right?
So, internally, we do that as well. Roberto always sends me a message like, hey. I'm like, we've seen this great new feature. But it yeah.
With customers, we see it as well. If they spend time to continuously learn, develop not only Salesforce, but also the tooling around it, then they, are more productive.
So that this sort of this culture change, there have been a number of questions coming in in in the chat the chat about how do I how do I convince my senior management this is important? How do I how do I bring these two teams together?
So what what do you see the challenges are? I mean, clearly, if not every not everybody's doing it, so clearly it's not easy to do. So where where are the challenges?
Again, feel free for all of you to jump in. But what do you see the biggest pitfalls or the challenges that we should be worried about as we approach this this journey into DevOps?
One of the challenges is is is is as as it said, you need, so you need, I think, two key things. Right? So you need key sponsorship from the directors of the company, from management.
So, it's proven. So, whenever you have a standardized process, you can repeat and repeat and improve also. Right? Because in in every, DevOps process, you start small. Maybe you start with a few sets of metadata types. The ones that you change more often, maybe still some stuff that you for example, reports, you can change them in production because some users want to create their own reports.
But you need to have that sponsorship. So because that needs to empower the organization. And then you need, like, Jen was saying, taking the time, you know, blocking some hours for, getting familiar with the process, also improving the process because in every release, you will identify, hey. Now we are working with this new metadata type, and we see that, there are these issues.
So maybe we can do that. Maybe we can generate some test data that can help to facilitate the the testing to do this and that test a lot easier, so saving time. So and and also documenting it. So and I I really like that.
I like the wiki style type of documentation with tools like, for example, confluence, etcetera. But there's a lot of tools in the market, where you can, you know, keep your documentation live and, people changing. Hey. I'm following a process, but I see that I get stuck because now I get translations with surveys.
I don't know if you ever had done that, but that's very tricky. So how do you solve that? Well, if you are now working with service in multiple languages because you have communities in Salesforce with different languages, then you can you can add kind of an exception to the process or improve on that. So it's it's an ongoing process where you will, get this level of maturity where you can be doing, like, Gerset was explaining a lot of releases per day.
So that's, very small increments. So that's one of the key successes for having a good DevOps. Very small releases.
So the risk is really small, and you have the tools that help you to go through your pipeline with this, yeah, with this process.
So I think I heard executive buy in and then a clearly defined process, and then then start with some small increments, get some early wins, start to then start to prove prove the business case.
So the the rest of you, and that's Greg. What what else do you see that the hurdles are?
Yeah. And and I was just gonna touch on that buy in piece because I think that's frequently, a major hurdle for teams, who want to implement buy in but can't quite sell the value to senior management or want to implement DevOps but can't quite sell the value to senior management.
I think on that side, you know, the two business value levers are really quality.
Right? Quality of your solutions and velocity of, you know, getting more done with the same amount of people. And, you know, you could take a very data driven approach to this of, you know, identifying bugs that are caused by deployment issues and tracking those and, you know, putting dollars and cents to that or or tracking, you know, lead time for how long things take to get to production users.
But also just even sending out surveys, to kind of business users and maybe some of the folks on the ground on the dev and admin team can frequently help uncover some of your pain points and issues in a way that you can get buy in, from senior management to resolve them.
I see that as that's a lot of the times, you know, a very big hurdle to clear.
We're just getting buy in from all the right stakeholders on DevOps.
And I would really second that you wanna start small and incrementally improve the process. Right? If you're in a large enterprise organization trying to, you know, solve all your issues and fix everything with DevOps in one go is just never gonna work, you know, just really you know, you can have a big vision of where you wanna get to in an overall plan, but really try and slice it down to small incremental, improvements that you can make that are gonna, you know, deliver value.
Yeah. And I I would also add to that. I think some of the challenges because it's new and because there's so much to it, there's potentially, it looks very daunting. It can look very overwhelming, especially when you look at how mature some DevOps can get. The the idea of of approaching all of that at once is is a really big task Where, actually, I think, Greg's really right. Like, slice it down, get it into small increments, and, actually, the process can be done small over time, and the buy in is really you know, Salesforce is one of the biggest strategic investments for your company. So if you're gonna invest that money into it, you need to make sure that it's aligning with your business goals and you're making it as efficient as possible for your company to get the most out of it.
That I mean, that picking that up, that suggests that DevOps is not something you switch on. It's actually a project you implement alongside the changes you're making. So you need to need to approach in that way the way we talked about. Roberto talked about sponsorship.
Greg talked about actually small increments. So I think someone needs to be the champion of of DevOps and saying this is a different way we're working. And and I think that's drawing together both the the declarative side saying because, well, we don't need DevOps because we're clicks not coded. And that clearly isn't true.
So therefore, there's there's a there's a journey, I think, that as you see that that people need to go through. So I I've been picking up some of the questions from the chat as we're going through.
So the other one is, do we need dedicated team? Do we need a DevOps team, or is it how how are we gonna organize this? Do we have release managers and then admin sitter? How are you seeing this organized? Is it and does somebody own DevOps?
Yeah. It really depends, depend on on the size of the team. Right? I've, I I I've had the small customers who want to get into DevOps, so they invest in these tools, so that they can, maybe run a project with us and then see how it works.
So we define what are the, for example, the quality gates that we want to define, like the environments. We have the dev. We have the QA. We have the SIT environment, the UAT, the production, and the hotfix.
So yes.
Yeah. Sorry. I I lost I was a bit distracted.
We we we were thinking about is this is there someone who owns the DevOps tool? So let's think where where in the organization is this? Is this the platform owner? Is this the CIO?
What who who should if I'm sitting here going, I really want to do this, who do I take the business case to and say, I think I need to do this. I've read the survey. I've attended this session. There is a huge business case.
Who should I be talking to in my organization?
Yeah. You you you need to be talking to one of your, architects, maybe an enterprise architect, that, can help you, that is willing to, get to one of these tools or to create the process from scratch. So starting evaluating how how you can start. So, yeah, that that's what I would say.
I also think it depends a bit on on the type of organization. Right? So that, definitely, if you have multiple teams and you have a release manager, it's good that that person totally understands what Gearset is and what it does, of course. But I I think the nice thing about tools like Gearset is because it's so easy, and at some point, you just get what's possible and and what's not possible.
It's easy to build up multiple people who will be subject matter experts. So if something goes wrong, then ideally, in every team you have, well, depending on the size of your team. But ideally, you have multiple people who are able to troubleshoot things because that's one of the advantages. Right?
If you build the whole CI yourself with Jenkins, it's great if it works. But as soon as it breaks down, that one guy is always on PTO. And if he isn't on PTO, then he has, like, ten other user stories which need more priority. I think that's also really nice thing about these kinds of tools is that it's really easy and, of course, sometimes painful with the metadata API, but it it's more easy to find out what the problem is and and fix it.
But I guess finding the budget depends just on the organization and and and who needs to sign that off.
Yeah. And, I mean, this is really gonna vary, especially for regulated industry. Sometimes you just need several levels of separation for compliance reasons.
The the one rule of thumb, I would say, is that you should try and keep your Salesforce DevOps and release management activities within your Salesforce group. So if anytime, you know, your Salesforce team needs any kind of change to the DevOps process, they need to go to a central DevOps organization.
That can introduce some friction. And as much as possible, you want that group of you know, maybe it's a release manager, maybe it's your lead Salesforce architect, whoever it is. You want that person to sit within the Salesforce team so that that team can somewhat self serve on this.
So, we've we've got a few minutes left. This has been a fantastic discussion. I mean, I could happily talk to you for the rest of the day, but I know some of you are in the UK, and it's it's, it's getting late to the evening.
So let's just go around around the panel.
What if you had one tip for DevOps success, what would that be?
Roberto.
Yes. Investing time, understanding the the release process, transferring the this knowledge to all the members of the team. Use these Wiki style tools, to document your process so it's not like something which is, putting a PDF that nobody can change. It's a living process.
So investing time on on explaining the people, taking a lead architect, like I was saying earlier, to maybe help to lead this, who has had experience in this type of of DevOps tools. You can get, in the case when I I I got working with Gearset, they have, they have the support chat. So you can you can, very easily, like, within three minutes, I I was saying average, you get an answer. So and whenever you get stuck, you you you you get support on these tools.
So that's also kind of an advantage that if you start with these tools, you you always will get support. And, yeah. So yeah. That that will be my my top recommendation.
Sam?
Well, I could be really cheeky here and say make sure that you put gear set in place, but I think probably I'll go down a different route. So, I think strip away the complexity is really important. Just start with what you need for your organization at that time. Start small, build slowly, and it doesn't need to be scary. So just strip away the complexity that you think you've got with the DevOps solution. Go back to the beginning and do it in small increments.
Jan?
Yeah. I I agree with everything that's been said, and I I think my top tip would align most with what Sam has already been saying. Like, keep it simple because, it's super exciting, everything, but it's also difficult some points. Like, we saw in earlier, presentations around branching strategies. There's really cool stuff there, but it becomes complex so quickly. And if the business is already used to a certain thing, like they, oh, we can go to production twice a day or once a day, it's really hard to pedal back from that. And the complexity or org becomes the more steps you need to take to make sure that release is stable.
So I would really say you need to keep it as simple. Don't think that you are Netflix or Amazon or Gear Sets, which releases twice a day. And and just start doing that. Make it more complex if if there's a business need for it. But if you can keep it simple, do that. And if it needs to become more complex, make sure that you have your automated testing and all that stuff, nailed down.
Greg.
You gave me the hardest one to answer that last. So I I would say, also agree with everything that's been said. But my last point would really be don't skimp on, training and enablement for your team. Right? If the team doesn't feel like they have the support they need and they can't effectively leverage, the tools. Right? Whatever process or tools you put in place are not gonna be effective if the team, you know, admins and developers is not fully onboard and enabled.
Fantastic. And that's that's that's a great summary. Thank you so much for all of the panelists for joining us, taking time out of their their valuable day. But I think this is this has been really insightful. As I said, all of this has been recorded for for those of you who wanna go back and actually pull out some of those snippets, some of those gems, need to use it to go back to senior management to build a case. So thank you very much. I'll hand over to Ben now who will close out the day.
Great.
