Description
In this panel discussion, Eloise Bloniarz from Gearset is joined by Andrew Montemayor, Salesforce System Architect at Axalta, Melanie Schock, DevOps Engineer at Bosch and Trey Flowers, Principal Technical Architect at Salesforce to discuss practical lessons from their DevOps journeys. During the session they discuss:
- Common challenges manufacturing teams face when scaling Salesforce delivery
- The challenges of coordinating releases across distributed teams and business units
- Balancing speed with compliance and risk reduction
- Approaches to improve release consistency and visibility
Learn more:
Transcript
Welcome, everyone.
So before we jump into the main session, I'd love to take a moment to introduce our speakers today. We're really fortunate to have three fantastic guests joining us, each bringing a slightly different perspective on Salesforce delivery from enterprise architecture to DevOps leadership to platform strategy.
And what's great about today's panel is that these are all people who are deeply involved in real world Salesforce delivery at scale. So you'll be hearing very practical insights from teams that are actively doing this work every day or working very closely with teams who are doing this work every day. We have a really good panel today who of people who are deeply involved in the real Salesforce delivery at scale.
We have Melanie. She is a DevOps engineer at BOSS where she manage BOSS. Sorry. Where she manages the end to end release process and development tool chain for a global Salesforce team.
She originally joined BOSS as a web developer before moving into Salesforce release management, supporting a team that has grown from fifteen to more than sixty developers worldwide. Today, she leads CICD processes, release planning, and team enablement, helping scale development practices across international teams. We're also joined by Andrew. Andrew is the lead Salesforce architect at Axalta Coding Systems, supporting a global manufacturing organization with more than five thousand internal users.
He leads platform governance, architectural standards, and DevOps strategy across a forty person cross functional team.
Andrew spearheaded a multi year transformation from change sets to a formal enterprise release management framework, strengthening scalability and reducing platform risk. And outside of his enterprise responsibilities, he's an active leader in the Salesforce community, serving as a community group leader.
And last then last but not least, we have Trey. Trey is a principal technical architect at Salesforce with more than a decade of experience on the platform. He began his he began his Salesforce career as a developer in twenty twelve and now works with enterprise organizations to design scalable architectures and guide complex platform transformations. Trey brings deep expertise in DevOps architecture and platform strategy to help teams build and operate Salesforce at scale.
Brilliant. Okay. So with that, and with the little technical blip in the very beginning, welcome everyone. We have a fantastic panel lined up today.
So we're going to spend some time talking about what it really takes to standardize Salesforce delivery, especially as teams grow, organizations become more global, and development velocity increases.
And for everyone that has joined, we'll also make sure to leave some time for questions at the end. So if anything comes to mind during the discussion, please feel free to drop it into the chat and we'll pick those up later on. So with that, let's jump in.
So a lot of teams start out managing deployments with a small group of admins or developers, but things start to change once Salesforce becomes a mission critical platform across the organization.
I'll ask Trey this first one, and then please everyone jump in. Trey, from your experience working with large enterprises, what makes Salesforce DevOps and enterprises uniquely challenging?
Yeah. So thanks again for having me here today.
What makes it uniquely challenging that I see a lot of times is in the the DevOps process for Salesforce. A lot of times you have, some less technical people involved in the actual development and configuration process. So making it as as, you know, easy for those people to use while also making it as complex as it needs to be for, you know, a a full on engineer can be a bit of a balance.
Yeah. Absolutely. I agree with that a hundred percent.
With our organization, we've got anything from ******** coders all the way down to business key users playing a role in our DevOps process. So when you've got that wide range of skill sets, being able to have it easy enough that everybody can understand it, but robust enough that it can handle the most complex type of situations for DevOps is a rather unique challenge.
Definitely. I also agree here. And I would also add that no matter how many people you have, you still need to have the complete range because you do definitely have DEFs involved and admins involved, and that makes it challenging no matter if you're five people or fifty, I would say, and everyone needs some technical knowledge definitely in the background.
Thanks, Melanie and Trey and Andrew. What are some common pain points that you've seen when multiple teams are deploying into shared environments on different cadences? And apart from that, what are some just common challenges that you see with scaling Salesforce deployment processes?
So I can start. I can say from our perspective is the more people are involved, the more chaos or chaotic it can get to not override changes of other people that they did before, that everyone really, yeah, takes care about the processes that are defined and, yeah, really doesn't override changes that are already there.
I think this is yeah. Especially the thing that you need to take care about.
Yeah. That's definitely probably the most obvious one.
Obviously, wrote overriding changes when you have a large team is a huge risk.
For me personally, a large team also increases the volume of change requests. And then we get into governance issues. Right? If you don't have a formal process in place to help with governance, just overall system governance, best practice, you run risks just to the system in general, let alone overriding changes that are in flight. So larger team, more complexity, just it just keeps getting worse and worse. So really making sure you've got foundational process in place as you're scaling is super important.
Yeah. I'll echo both of those.
The two main things that I see working with customers are just governance has to be, like, super tight. You have to you have to have a really strong COE. You have to have executive buy in, and they understand the importance of Salesforce as a tool, but also DevOps and making sure that, you know, you don't want your system to go down because of someone making, you know, causing a or promoting a bug into production. And then the other one is, you know, doing volume testing and integration testing as early in the process as you can, so you're not waiting until you're, like, in a UAT environment or something like that when you actually have production level data volumes. So, those are the two things that I've kinda seen the most.
And I would also add, that it's very, very important to not differentiate between, the development itself or the the administrative tasks that you do in Salesforce, but also count in the deployment as a task already from the beginning because this is what people keep on forgetting that if they have developed something on an environment and they want to move it to the next one, this also is part of the whole work they are doing. And I think this needs to be part of the process and also needs to be in the heads from the beginning, not only for the Salesforce development team, I will call it here, but also for everyone who's involved to make this work that is behind here, so the DevOps work, to make this visible from the beginning.
That's actually an outstanding point. It's very common, and we see this with project management teams quite often, that they don't factor in the time it takes to move changes.
Right? Part of the process is reviewing the changes that are being made, getting them approved, but then actually transporting them up the pipeline.
That all takes time. And when they don't factor that in, suddenly everything seems to be running late.
We had these target dates, and we're not hitting them. Why? Well, because you didn't factor in the time it takes to deploy all this stuff. And big packages can take a while to deploy.
I wish I could say that every deployment went silky smooth. You just press the button. Boom. It slides in.
Never seems to be that way.
Even the most basic deployments can be problematic for whatever strange error that the the system's gonna throw back in your face.
So, yeah, you've gotta factor in the time to actually move your changes. That's important.
Yep. And it it also really helps having someone who is dedicated to to the DevOps process, especially in larger enterprises. Some someone that can kinda shepherd, you know, DevOps along. Right? And and that knows everything that's going into production and is able to keep a handle on how to how to push what when, rather than just having it as kind of a a secondary responsibility. And again, I know that's kind of a privilege of of a larger enterprise where you can actually have something like that, but that also helps with that.
The conversation around, like, you know, what you were saying, Andrew, it's like, oh, we have this last minute change and that's it's really easy for leadership just to be like, oh, you know, we just we need this in now. Just, you know, put it in a hot fix sandbox, push it in. We'll we'll worry about, you know, source control later type thing.
So, just strong governance, executive buy in, and, you know, a a strong DevOps, head for that.
Yeah. That's something that I fought with for years. When we were first ramping up into a real formal DevOps process, yours truly was the one that was tasked with deployments.
And I've got a whole different job. Right? That's not my role. But I found myself spending huge amounts of time just on DevOps.
And we finally were able to secure a release manager, which I'm so happy about. It makes a huge difference to have someone dedicated. That's all they do. In an enterprise level scenario, you gotta have it.
That's all really interesting, feedback. Governance in play needs to be in place. That's what we've heard consistently. Strong COE, executive buy in, Trey, you mentioned, training in the right team, Melanie.
I think that's what you said. And then factoring the time to move those changes. Sandra, you agreed with that point. On the governance piece, since, you know, you you all work in or or with large enterprise organizations, I'm assuming that that's a really critical piece to scaling your your DevOps practices and processes.
Can you talk a little bit more in terms of what that looks like and how that needs to develop?
Well, for us, we slowly developed our governance process.
Really, a lot of trial and error went into it. But now when a change request comes in, it gets logged. For us, it gets logged in Salesforce. And then once the initial request is approved, right, it makes sense.
It's not gonna break things for other folks. Just that initial review happens. The developers get approval to go and develop a solution. Right?
They'll come back with their solution before it leaves a dev box and moves up the pipeline at all. It goes through a review process. So we're seeing exactly what's been developed. We're checking to make sure it was done via our governance policies because we've got corporate governance policies that we have to follow.
Then we also do code review at that point. Right? My technical architect goes in, actually reviews the quality of the code. Are the changes up to spec?
Is there anything else in that code that might need to be tweaked to make sure that we keep up with the latest greatest standards of Salesforce? Only then does it get approval to be promoted even to a QA environment. It doesn't leave the dev box until it's gone through that initial review gate. And for us, that was critical because if you wait till later, right, let's say that you have dev to QA to UAT and then up to production.
If you wait to UAT to do that review and they've done things wrong, then you have to go back, refactor, and then do your QA again. Right? So before you even move out of a dev box, in my opinion, it should be reviewed and approved.
Melanie, are you seeing, similar things within Bosch as well?
Yes, definitely. So we have a very strong review process in place already coming from the deaf environments. Yes.
What we additionally have at a later point in time then when we are already on a QA sandbox, We we do have test automation in place. So so this is also part of the of the DevOps process to, yeah, with one click, run some automated tests already.
Of course, there will then also be manual testing and then approvals from different sites in the end. So everyone has to agree before we really push something to a production environment, and we do have a lot of check marks in the end, a lot of people involved before we push something to a production environment.
And, yeah, from our perspective, it's a lot of so DevOps is is very much involved here and very critical also, a a critical position.
Brilliant. And, Trey, you mentioned a strong COE. Would you add anything to that?
I feel like I've said it with every answer, but strong executive buy in, top down, like, understanding of of what is actually needed. I think that's how you're able to to get all the resources you need to make a good COE and a good DevOps team pipeline release management, all of that.
Without good top down, it's it's you're just not gonna get the resources you need.
That makes sense. That makes sense. And probably some companies don't have that COE structure in place, so it's it's interesting to hear that across the board.
So it it sounds like dev dev ops isn't just about speed. It's also about that governance and security piece as well as as we're talking about governance. But, Melina, you mentioned automation, so I'd love to understand, you know, how do initiatives like AI or just automation in general influence your processes?
So I can already add. So AI does definitely help us in speeding up the coding, maybe speed up the development. But still so from my perspective, it still doesn't fix a poor organizational process or ownership, I would say. So from my perspective, we have to be, yes, definitely use it.
Get used to it as well. I think we're still in the in the phase of of learning with it, but we do have to have defined processes still.
It will also not remove governance topics, I would say.
So that's that's my perspective at the moment.
Yeah. Okay. AI is still too new for us. We're sticking our toe in the water.
We'll be testing it out later this year for certain aspects of our system. But when it comes to DevOps, yeah. I agree with Melanie. All the all the governance, all the process, that's not AI.
Right? That's just straight up good best practice. For the testing, we're looking into that now. I mean, automated testing has been on our hit list for quite some time.
And we started down the path a couple times only to find that the tool that we selected wasn't really up to par. So, yeah, we're still pursuing that piece. I think it's an awesome idea. If you can get it, get it.
Automated regression testing is huge. And I think it's a monster time saver. So I'm all on board with it. Wish I had it, but hopefully coming soon.
So much to unpack there.
I wanted to just quickly because we did have a question in the chat as well. So I wanted to just ask Maria's question to the panel. So Maria asks, what do you consider a team size to be for enterprise level?
Because she's only worked on smaller scrum teams, less than fifteen people with active developers, architects, testers of six people. Any thoughts for that?
Yeah. That's tough.
Enterprise is more about the size of the system than necessarily the team. I've found that it's not uncommon that a Salesforce customer will understaff. Right? They go in, they buy this fancy tool, and think, great, I just need an admin and a developer. I'm cool.
Then suddenly they realize how demanding it is to support the system.
And it all comes down to the budget, obviously, You know, what can you afford? But an enterprise level team, in my mind, you've actually got multiple teams working together to support an enterprise.
I don't think enterprise is like a group working a series of issues together through scrums. Right? It's more like multiple teams. So for us, CRM team, ecommerce team are split into two separate distinct groups.
Then we've got our contractors that come in.
So it's the multiple team aspect, I think, that leads me towards enterprise tagging to be able to say this is an enterprise level team is it's to group effort.
It's not a development team, but a group of teams. That's my opinion.
Yeah. It's it's pretty subjective. It's not really a a team count. I think it's more about the number of dev streams, the the what systems or or what processes are running through your Salesforce system. Are they mission critical? Are they revenue generating?
You know, all those things factor in to what classifies an enterprise, you know, type system and team.
But, yeah, it very subjective.
Thank you, folks. Maria, I hope that answers your question. So, thank you so much to the panelists today.
I can't believe it's already been thirty minutes, but Trey and Melody and Andrew for also, thank you, of course, for sharing your experiences and your insights. It's been really interesting hearing how different organizations are approaching Salesforce DevOps and scaling delivery across large teams.
And thank you everyone who joined us today from all around the world as well. So if everyone can see that, this is a QR code, if you do want to book a consultation with Gearset. But once again, thank you to everyone from all over the world, from the US, from Germany, from Spain.
Great engagement in the chat. If you do have any follow-up questions, please do follow-up with us.
Very good. Great. Thanks, everybody.
Thanks, everyone.
Everyone.
Bye bye.
