How to master Salesforce DevOps panel summit 2022

Share with

Description

Join Blanca Leon-Carter, DevOps Architect and Principal Consultant at Slalom and Debra Weller, Enterprise Technical Architect at Rain focus as they discuss how to master Salesforce DevOps. This panel is taken from the Summit, hosted by Melissa Shepard.

Topics discussed:

  • What is the current state of play and future of DevOps?
  • What’s the most important area of Salesforce DevOps right now?
  • How important is full implementation of Salesforce DX in terms of success in DevOps?

Learn more:

Related videos:

Transcript

Next up, we have Blanca Leon Carter. She's a Salesforce DevOps architect at Slalom as well as Deborah Weller. She's an enterprise technical architect at Rain Focus.

And, Blanca and Deborah, if you could just, tell us a bit about yourselves, that'd be great.

Sorry. There was a little bit of lag as I was upgraded to panelists. Did you want me to lead with that?

Sure.

Hi, everyone. I'm Blanca as Melissa mentioned. I started this journey originally as, a director of IT and operations in the nonprofit space and doing a Salesforce implementation, at that organization. I later then became the in house admin.

And fast forward a few years, I pivoted out of nonprofit into higher ed working with, enterprise, level, Salesforce orgs, having multiple orgs and very confusing DevOps processes that were very siloed and managed by a few people. And now, fast forward into consulting for the last two and a half years, where I've learned that there's a variety of differentiation amongst clients and how their DevOps is working or not working for them. So I spent, the last almost two years, investing a whole lot of time in this space to help, create awareness and drive conversations and bring others to the table and and talk about what it could look like and how you can make it work for you.

Thanks so much. Deborah, are you there? Would you like to introduce yourself?

Yes. Hi. Thanks, Melissa. Hey, Blanca. I'm Deborah Weller. I'm with RingFocus, and I'm an enterprise technical architect here. We're a small company, and I was previously with some large enterprise orgs, working in the Salesforce ecosystem.

And coming back to a smaller company, having a small team, and being able to to really design our own processes has been so great over the last six months, and we're really trying to embrace the DevOps journey, making some small changes and, automating our workflow. So I think it's it's it's been a a blessing to do that. So, hello. I'm joining you from Utah today.

Alright. So this panel is gonna be, what it takes to master Salesforce DevOps. So I have a few questions to ask you both. The first one is, what is the current state of play in the future for DevOps?

I feel like this is a game show.

Yeah. For the current state, I think that, there has been some changes in the Salesforce ecosystem, right, with the introduction of SFDX. And I think that, with Salesforce's model, you know, to preference code and I mean, preference clicks and not code. Certainly, we do need code. And, yes, it's nice when you can do certain things on the declarative side, but I think there's this movement towards how to bring, team members from different spectrums, admin and developers and others, together for the better movement of improving DevOps within their companies.

Yep. Completely agree with that. Deborah, do you have anything to add to this?

Yeah. I I agree with that too. And I think, there's a lot of focus on DevOps. It's like the hot thing, but it really comes down to there's great technology for it.

We're seeing some of that today, but it comes down back to the people and the processes. And if you don't have if you don't if you don't embrace the people, bring everybody along with you and figure out how to make it work for your folks, it's not gonna work. And if you don't as Claudia was mentioning in the last, the last session, if you don't figure out how you want your process to operate before you choose all the tools and start to layer in the complexity, you're not gonna get there. So the current state of play, I think, it's becoming more inclusive, to get your stakeholders and your your, your admins, not just your developers, but your admins as well in to, the process to, run your run your stuff.

And I think there's that element of, there's a lot going on. Right? Especially with COVID and companies having to move to, you know, cloud based systems versus, you know, on premise and other ones. I think there are more and more people who are leveraging Salesforce, and you have more people building within the system.

Right? Config and those on the programmatic side. And I think that there's these three elements that were highlighted that I took note of within the gear set dev ops, state of dev ops report from twenty twenty one. And, you know, that's looking at, of course, introducing tooling, but making sure it's the right tooling or right set of tools because sometimes it's not just one.

And and then also looking at, you know, what is your continuous improvement, continuous integration, continuous delivery look like because we can always be improving in the area. And if you haven't started to look at it, it's never too late to start. And I think the other one is just figuring out how do we we move to a source driven path. Right?

Where it's it's less chaos and it's more we can track and have more control over what's being done, when it's being done, and who it's being done by, and and be more fluid with what's going on in your work.

Also getting some of that automation in there. I'd you you touched on that, but if we can get the that stuff running in the background so people don't have to think it's very easy, it's very easy to do the right thing, it's very easy to use the source driven model, That's gonna make everything better, less chaos as you were saying, Blanca.

I will say it's not always easy right off the bat. Right? It's not like riding a bike. I think sometimes there's pain points.

When I was learning to ride a bike, I got a black eye. And sometimes trying to learn how DevOps works for your company, you might get a few pain points like that as well, but I think there's this embracing sense of collaboration and bringing some resilience, to the organization and your processes is gonna help you get further along quicker.

Absolutely.

The next question is, what's the most important area of Salesforce DevOps right now?

That's a tough one. I think we touched on it a little bit. I I do think it the one of the biggest challenges in having worked with Salesforce for since, I don't know, two thousand six, worked with dev teams to bring some of the DevOps practices, but being able to bring the other people into it as well. So make it easy for your admins to get in.

My company, we are really focused on, doing as much as we can with declarative. We only write code if we absolutely have to. So it's very easy to make all those changes directly in production, and we're trying to, you know, not do that, trying to get into a better cadence where we're we are using the the lower environment and promoting stuff automatically, doing the branching. But, I think it's it's it's around, bringing everyone into the table.

My PM can get into it. Our stakeholders can can help. Our admins can help, not just our developers.

And I think that it's about, creating a culture of, empowerment. Right? There's a level of education that needs to be done for everyone involved. Right?

And sometimes it's bringing new people who weren't at that table before, to be a part of that conversation and drive that that collective, outcome of, you know, what is our plan? What does it look like? Is this working for us? How can we make it better?

Continuously assessing and seeing where you are, because it's it's gonna change over time as your business needs change and your team dynamics change and, you introduce new systems, new tooling, etcetera. So I think that is a very important piece. I also think, trying to get ahead of the curve is is very important. And I I can't say that you're ever ahead of it unless you're in this luminary as Garset has on their maturity journey.

I have yet to meet someone who who's at a team that is in the luminary section. So if you're out there, ping me on LinkedIn because I'd like to learn more from you. But I do think that there's this investment, right, of time and resources resources not just in in the experts within those areas of specialty that you need to bring to the table, but then also, you know, like, your set just got a big investment. Right?

And and I think that companies need to look at, part of that return in investing. You have to find a way to rationalize and budget for it because it is a dire need. And and if you're not, allocating the right amount of resources, from all of those, aspects of what you need, you're gonna hit barriers and roadblocks that can deter you from being successful or how slow. Right?

The question came up in the last session with Claudia. You know, what kind of time frame does it take to, you know, implement DevOps best practices and and and a plan that works. And that all is unique to your, company.

I think also we've, we wanna make sure that or or at least I I get the the from the business stakeholder, that that sounds great. We're glad that you wanna do that. But is that gonna slow down how fast I can get my features and how fast you can deliver, how fast you can help turn around our fixes or our new feature requests? So, it's trying it's being able to show people and some of those those metrics we talked about before, but being able to show people that it's it's actually gonna make things better. It's not not gonna slow us down. We do have the the process in place to get a hotfix in if we need it between our weeklies branch or something like that, and and develop that confidence with your stakeholders. So, it's a learning process all the way around.

And sometimes those executives don't get the moment until you have those major failures. Right? Those major outages that are hitting everybody. And then support calls are coming in left and right, and people are at your desk get mad at you at, what did you break with this deployment this time?

And sometimes it's a matter of having those metrics that you just spoke of and and painting that picture. Look. These are minor failures right now, but we can take control and prevent them from getting to that major point. That's part of getting ahead of the curve as well.

The the other thing with, being able as you're developing features and you're doing fixes to assess the risk and assess what could possibly happen. If you've got a better process in place and you've got some automated testing in place, you can be more confident that you're not going to introduce unintended, problems into your environment. So it's sort of that's it's it's a it's a it's a slope up to get there, but once you get there, I think, it you can reap the benefits. It just is gonna, snowball at that point.

Next, we have a question from the audience. So, why is it so complex to implement version control and development pipelines with Salesforce to the extent that it requires paid third party solutions like Gearset?

Utilizing Git and version control with software development is considerably easier and better documented, but most products that offer this with Salesforce seem to overcomplicate the process and setup. Is this a function of retrofitting traditional SDLC best practices into a platform that was not built with them in mind?

That's a Oh, go ahead.

Sorry, Blanca.

No. I was just gonna say, I think that's an area that we know is gray, and there's a lot of ambiguity. And I think that we know we're falling short. Right?

I think Salesforce themselves has invested a good amount of time in developing the DevOps center with the hopes that we can provide more access to both admins and developers to work, in in the same with the same kind of tooling, to achieve better best, DevOps, you know, outcomes. I think that, other companies like yours said, you know, have invested a lot of time in in building out before DevOps center is even there. It's not even GA yet, right, to fill that gap. But I think that we're always looking how to iterate because there is not a one size fits all.

So what makes sense for Deborah's company may not works, make sense for one of my clients. And so it it poses a challenge for companies who are developing these types of tools, and that feedback is something that I know that I am always, very adamantly vocalizing. You know, taking back what I hear from my development teams within my consulting firm and what I hear from our clients and what I hear from community members in the trailblazer community, they need to hear that. They wanna hear that because then they know to take that back to the right product owners who are building out and trying to make it easier and better their platforms to further assist you.

I think the, the question, you know, we've been using these tools that gets get in version control in the software development life cycle very easily, outside of Salesforce. Why is it so so hard to bring it into Salesforce? And I don't know if anyone else has tried to work with a team that isn't Salesforce savvy or has been doing more traditional greenfield development than trying to help with your air quotes around the help with your Salesforce, implementation and trying to explain to them all of the nuances about how you create and deploy things within Salesforce. It's a it is different.

So it is a little bit more specialized, and it's exciting to see the stuff coming out with, like, the DevOps console. But just the fact that Salesforce wrote the the tooling API and the metadata APIs and that these other companies are taking advantage of those things to be able to make everything easier to deploy is great. I've I've I've I've appreciate that we have that many different, options because it is up to how your team wants to work and how the challenges you face. My challenges aren't necessarily gonna be your challenges.

So that's And I think with the variety of options that Deborah mentioned, you know, they with all of the tooling, I think it was Salesforce then has, like, a periodic table that was released a few months ago of, like, all the different vendors and tools that you can use to to support DevOps.

Right? And that's a pretty hefty selection if you look at the whole periodic table. I think it's understanding that becoming acquainted with them, when you're vetting them, really do your due diligence to make sure that you're not just take drinking the Kool Aid when their salesperson says, oh, yeah. We can meet this need and oh, yeah.

It's like, okay. Show me how. And then challenge and ask about, okay. What are the caveats I should know about?

What are some of the limitations that you know you have that you're gonna be working on in the next few quarters or a year, so that we know what's on the road map? Because then you're gonna be more informed to make a better decision, when it comes to purchasing different you know, buying into different subscriptions with these tooling services.

Alright. Next question. So how do you turn around an ineffective DevOps process? So, basically, not starting from zero.

That's a good question. And I, I like to think that there has to be an element of what is your mindset going into it. Right? I think that oftentimes what I've seen go wrong is that we start blaming team members and we start blaming teams and we start putting, you know, responsibility on someone else.

And and, really, what we need to do is get past that blame game. Don't do that. It's only gonna hurt you. I think it's go to your metrics that Deborah mentioned.

Look at the reports that you have that are supporting where the bottlenecks are, where the pain points and conflicts are coming up, and and help prioritize or or help drive the conversations where you and your team and the correct stakeholders can prioritize, how you wanna start improving. Right? Because I think in the session before, it was stated, and I'm sure it was stated a a lot because even at, DevOps streaming, it was said that DevOps is not a sprint. This is not like wave a magic wand and poof, it's done.

It's gonna take hard work. It's like cultivating a garden. You know, you're gonna have some bad roots. You're gonna have to pull out, and you're just gonna have to regrow and build on the ground up. It's a matter of how much do you how many how much in resources, how how much in support because you're gonna need an executive sponsor, and what is the best, you know, rollout of phases based on your priorities and your abilities.

I like what you said there about, like, stopping the blame game because it becomes a psychological safety issue when you're trying to make things better, but you just if you raise your voice, you feel like you're just gonna get, you know, slapped for it because it's you know, someone's gonna blame you for it. So trying to get out of that is is important. It's all bringing people to the table and and having that kind of culture of what can we experiment with to make this better? What are some ideas? And we don't have to try all of them, but let's try something. Let's agree to all try something and then reevaluate.

It may be in our next retro or whatever your cadence is. Let's see how it works. And if it's not working, let's toss it. Let's figure out, how we can be creative together and identify what's going wrong and come up with some solutions for how we can fix it and start really small.

I think trying to turn around something that's in flight is hard. It's like trying to change, you know, your tire on your car when you're still driving it. It's hard to stop enough to work on it. So it's trying to get those incremental small changes, and then that can make some big differences over time.

I think the other thing too is, going back to the metrics. Right? And how do you have a conversation without going the blame game route? And I would say stick to facts.

Look for what are the facts. At what time did this happen? At what time and how many, you know, conflicts did we see? You know, go back and look at the timelines and what was done and when to stick to the facts and have them lead you along with your metrics.

So then it it it leaves it for each team member to feel that they have some value. Right? Even if something went wrong on their little piece of time in that whole development life cycle, it it leaves them to be able to still provide their expertise. That's what they're there for.

They specialize in whichever area, whether it's testing or whatever it may be. And this is another reason why people also look at different toolings, like you mentioned, Deborah, automation. Right? Like, testing automation is an area that is very time consuming.

We're humans. We're error prone. I mean, there's a lot of things going on in life, and and sometimes we're trying to manage too much. Right?

So anytime we can embrace, automations that can help make our life easier, somebody still needs to manage them, somebody still needs to configure them the right way. Right? That that, configuration and management needs to be that plan for it needs to be provided by your collective team who's weighing into the DevOps processes at your companies.

So try that out.

Great answers. Thank you.

Our next question is how important is full implementation of Salesforce DX development, specifically Scratch Orgs to the DevOps environment in terms of DevOps success?

I can take I can go give a go for that. So with the the DevOps process we're putting in place, we're not starting with Scratch Orgs and Salesforce DX. We're actually starting with coming up with a branching strategy to manage our different environments, making sure that any changes that are pushed to production are pushed back into the lower environments, including anything that might be held off to the side for, like, a larger implementation, something like that. But, I think we might get to Salesforce DX, and we might get to the scratch orgs, but we're not starting with that. And so I don't I think it's it's an option for you there that that fits into what you're needing to do, but you don't have to start with that.

I will say Scratch Orgs sometimes depending on I've seen different clients and different teams, and they have different, plans and different policies as it relates to DevOps. Some of them don't use scratch orgs at all. So it's not like you need, to go that route in order to find the proper, tools and and flavor that works for your team and your company.

If you if you look at something like Gearset where you can get really very granular about what you wanna push between different environments based on what's different, what the differences are. You don't have to take everything. You can be very, very, very small. So I think it removes some of the necessity to do the more the smaller scratch org deployment. So, yeah, I'd I'm not sure. I'm I can't really speak as an expert to scratch orgs because we're not really using them, but, it's definitely an option out there.

Alright. Next question. And this is a good one. I like this one. What are effective strategies for getting business stakeholders to buy into the DevOps transformation?

So I'll I'll I'll take a stab, Deborah. And I don't know that I had this, intended to as a response to effective strategies, but I think that it should be everyone's number one priority. So I actually had it shuffled under, future state, you know, DevOps, is this emphasis on trust. Right?

Like, security is obviously a big need, and and we need to uphold security and compliance. I think trusting within your teams, trusting within your company and how you do things, you know, trusting the metrics that are you're using to not only manage your business, but also manage your DevOps. Right? I think trusting in how you guys are going about upholding, best practices.

Right? Because not all best practices are gonna apply to your company. It's the ones that you choose to embrace, making sure that you stand by them, and and stick with that. I think the utmost goal is, you know, just because you can do it doesn't mean you should do it.

We hear that all the time in the sales force tool, and I think that the same applies for, DevOps. And I think that if you put in trust and you find the evidence that you need to support keeping the high quality trust levels, I think that's gonna be a good driver, that your executive stakeholders should be listening to.

Excellent. Excellent trust message.

And becoming that trusted adviser to your business stakeholders, I've seen it work really well with, having as, like, a product owner that represents, the bridge between those business stakeholders and the development teams to really understand what they need, be able to bring them suggestions when new things come out with the new like, the three releases a year for Salesforce, things like that. And then, really work understanding what the need is, not just be the order taker from, you know, put this field in, do this, that kind of thing. So develop that trusted relationship. I think that that plays into what you were talking about, Blanca.

I think too, before you approach any executive sponsor, right, and stakeholder and trying to get buy in, I think you should be ready with your research that you've already done to have your talking points, to have your metrics ready to go on the fly, so that you can very concisely, you know, convey to them what is the current state like now, and what could it possibly look like.

And when it comes to trying to get approvals to buy into different tooling, I think you need to provide some kinda, like, comparison matrix to show them, like, look, these are the features that this one has and that this one has, and these are the ones we need out of all of them. These are where the gap areas are. This is the cost that's, you know, relative to it. This is what we need to think about in terms of uptime and security wise and how that would bring peace of mind, right, to anyone who's approving for you to buy into that. So make sure you do your homework. Don't just rush through it. Don't just say, oh, I think we should and, like, no.

Say, I think we should because of x y z, and this is what I have to support it. And then, I think they'll be more inclined to listen, and you're gonna have a stronger pitch.

Right. Exactly. You really have to explain the why. Yeah.

Every get away on the same page for why and then be able to show those metrics that here's why we're doing what we're doing. Look at here's what we started with. Here's where we've gotten to. Here's the error rate. Here's the the number of deployments and the number of points we're able to deliver in each generation, that sort of thing. It's I think that's a good it's a little bit of internal PR. Right?

Talk up your team, but be able to show here's the results we're getting.

Alright. Here's another one. How important is a synced pipeline in your opinion? Have you locked down your middle environment so that teams are prevented from making manual changes?

I'll I'll start with that one. So we're just in the beginnings the start stages of implementing our pipelines. So, no, we haven't locked it down yet.

I think as we figure out how we want all the pieces to work, we're definitely going to put stocks in place to define who can push between which environments and what the automations are between those in the tooling.

But I it I don't think it's I think it would be great to be able to do that. I'm not sure it's possible to do all the time, but I'd be interested to know what you think about that, Blanca.

Yeah. I've seen different clients do it different ways. Some do have stops, some don't. I think if you don't have any, you have to make sure that communication and collaboration is very strong.

Right? Especially when you get into bigger orgs with more teams working in it simultaneously, you definitely don't want to step on each other's toes and you definitely don't want to set anyone back. Right? You need to make sure that you're moving forward, with the same configuration.

Otherwise, it gets really challenging to try to manage all of those merge conflicts when we talk about branching and and all of that. So I do think that if you don't have any, ways of of putting a stop to it, you have to really, really communicate, cross teams.

K. Alright.

One more question. Let's see. If what is the best practice for using a scratch org? How can we minimize the issues that come up while making deployments due to to the dependencies?

So I'm gonna have to plead the fifth on this one because we haven't been working a ton with the Scratch Works.

So I had no is gonna lead you in the wrong world down a long wrong road, but I'm sure there's some excellent experts who'd be happy to talk to you about that.

Yeah. I'm kind of in the same boat with Deborah, but what I've heard from, you know, other clients who are having folks, like development team members asking questions. I think sometimes it's looking at, you know, do you have tools in place that can help support without Scratch Orgs? And if you do have Scratch Orgs, connect with those in the Trailblazer community who are leaders with Scratch Works.

Right? Like, there's so many different user groups. I am a user group leader here in Chicago. I don't have expertise in Scratch Works, but mind you, if somebody came up to me, I'm gonna go searching with my Chicago crew first and then later on with the global crew of Trailblazer community to try to find out, who is, more experienced in that area so that they can support you.

So whoever asked that question, that is a fantastic one. I don't we don't have the answers today, but if you send me a message on LinkedIn, Blanca Leon Carter, I will find some folks down for you.

Great. Thank you so much. Thank you both for your time today. It's been a pleasure having this conversation with you, and, thank you for all your answers from the audience questions.