How do you know if your team is ready to adopt Salesforce DevOps?

Share with

Description

Is your team ready to adopt Salesforce DevOps? In this insightful video, Michael Halliwell (Salesforce Administrator at CareMax) discusses key indicators that signal your team’s preparedness for Salesforce DevOps.

Micheal runs through:

  • The issues you may be facing from not having a Salesforce DevOps process
  • How to allieviate these issues and pain points

Learn more:

Relevant videos:

Transcript

Everyone. My name is Michael Hollowell.

Today I'll be doing a talk on how to know if, your team is ready to adopt Salesforce DevOps, and it's more so focusing on some of the issues, that you might be experiencing from not having a DevOps process and some recommendations, to be able to alleviate, some of those issues and pain points.

So, Ian covered a little bit there, but a little more about me.

I've, I'm a Salesforce admin at CareMax we're a health care company.

And, I've been working in the Salesforce industry for about seven years now. And a moderator of the Salesforce Exchange Discord for about five years, just a quick plug for the Salesforce Exchange Discord.

We are a server that runs on the Discord platform. It's kinda like Slack. And, we're a community of, you know, I think ten thousand plus members now ranging from complete beginners, like that don't even know what Salesforce is. All the way to architects, you know, full stack devs, and, you know, just people that have been doing it for a long time.

So it's a great place to go to get help whether you, you know, are just getting into it or, you know, even need help, like, architecting, a complex integration or or project. So, definitely come check it out. Check us out. I'll have a link at the end of the presentation, if you wanna join.

So for the agenda today, some of the things you might be suffering from are overriding of changes in your metadata from, deployments, we'll go over balancing development and deployment time.

Some people are spending a lot more time, deploying than, working on new features, and it's there's a lot of wasted time there.

Also talk about some issues you might be having of Salesforce as a critical platform for the business, and how DevOps can benefit that. And, team frustrations, which ultimately, is, you know, without dev ops, that's that's where you end up is, frustrated teams and, you know, other departments and and leadership. So, and then lastly, we'll kinda I'll kinda recap and give my recommended next steps, you know, to start your DevOps journey.

Alright.

So getting into overriding changes, so if your company, if your team is suffering from frequent overwrites of metadata, this is gonna cause, you know, a lot of headache, for you, for the end users, you could potentially, you know, end up losing metadata, page layouts is one of the most common ones that I see where metadata is getting overwritten, especially in larger companies with, you know, larger admin and developer teams people will deploy page layout changes, and, you know, they'll be working with an out of date version of the layout. They'll send it up. And it makes its way to production.

Sometimes, you know, you might lose read only, checks on fields, fields that were required might no longer be required.

You know, you might end up killing a whole section of a page or accidentally removing buttons.

So, you know, these are all common things when, you're you're deploying layouts. So it's it's super crucial.

Know, to have a dev ops process to, to manage these types of changes.

You know, like, the this can also contribute to data loss. So if If you had a field that was required and it's no longer required, or you removed a field from the layout by mistake, and, you know, maybe that field was crucial to the finance department, for their quarterly, you know, reports that they do. Maybe it was, like, the industry field for a a company and you know, new all all the new accounts for the last quarter haven't been getting the industry. So now somebody's gotta go back and and figure out what the industry for all these accounts are before finance can can run their reports or, or maybe they've already run all their reports. And now they found the issues, and then they have to go back and do all the do all their work. So it can result in in data loss that way.

And, so but there there's a number of things you can do to prevent this.

One of the main ones is gonna be, version control. So, you know, if you deploy a layout in that sandbox, gets refreshed. And, you know, there's no longer, a recent version of the layout.

You're not gonna be able restore properly, and you're gonna have to go off your memory or maybe some old screenshots from, you know, user guides and try to build that, that layout back and Like I said, I mean, that can that can result in in data loss. So having version control, keeping track of every time you make that change and having a change log we'll we'll let you easily revert, revert back to a working state of the org. And so hopefully the impact is is minimized.

So, additionally, like, you can have regular data backups, which not so much related to overwriting of changes, but I did just wanna call it out since it's it's important.

Having regular data backups and testing that you're able to restore from those backups is gonna be super crucial, with dealing with data loss. And, you know, just just make sure you're practicing from them because there's many relationships There's a lot of relationships and objects. And if you forget to add, you know, a certain lookup field to your data backup, you're not gonna be able to properly restore those relationships. So, have backups, do regular backups daily if possible, and definitely test and and make sure that they're working.

Additionally, you can utilize tools for metadata comparison, like, When you're, when I deploy layouts, I like to look at the metadata and see what's currently, you know, in the environment that I'm going to and what am I deploying? And I will look and and go through the metadata and make sure that what I am deploying is the changes that I needed I'll often, you know, when I'm doing proof of concepting, in in a development org, I'll often add fields that are no longer needed and just forget to remove them. And when I'm going line by line in the metadata and seeing those changes, it makes it much easier to catch that I shouldn't have, you know, be bringing this field in, or I'm accidentally removing a button that I never meant to touch in the first place.

So, also, you can some tooling, that you can use has, deployment rules, which is, can be a really nice feature.

When you're working in larger orgs with big, large development teams, some, you know, layouts really is a big problem. And, a lot of companies actually just don't let people deploy layouts. It has to be manually done in prod, just because of the issue of metadata of getting overwritten.

So, deployment rules will actually let you, create rules around certain metadata types so that when you go to try to deploy that metadata type, it actually blocks you, so that can be a really great feature, to make sure that, you know, certain people are following process and and not doing, you know, deploying things they shouldn't.

In addition, you know, for the deployment rules, you can also a lot of tooling will let you, limit access, via the deployment tool, So you can, maybe, if you're working with a consulting partner, and they only need access to, like, sandbox in your staging environment and not production, then you can just give them access to the development and staging orgs, and you don't have to ever worry about them accidentally making like a breaking or overriding change, to production.

And then lastly, change approval boards are really great.

You know, you don't wanna over complicate it unless it's, you know, you you kinda wanna base it based on the severe severity of the change. So if you're just adding a pick list value, you may not need to, you know, send it up through ten levels of approval. But, you know, if it's a new feature or something like that change approval boards can be really good, especially, like, for peer review, if you've just created a a new feature, and you go to deploy it, and it goes through the change approval board. Somebody higher up that has more knowledge in the org may tell you, like, oh, you know, we don't actually need that because we're doing we're using some other product to solve it next year. I've seen it happen all the time where, you know, features get developed and they weren't needed. And unfortunately, you know, it didn't get caught sooner, but at least it's not making its way into production.

And having to, you know, be ripped back out.

So, additionally, with a change approval boards, it's a great it's a great way to, you know, open up the communication channels of of what's coming with the deployment.

So it's nice to know you know, like, as a department head, what what are you deploying so that I can prepare for it and make sure my team's ready and make sure it's been properly QA ed before we we deploy it and and break some things.

So, moving on to balancing development and deployment time.

So if you find that you're spending more time deploying than developing, that's gonna be a key indicator that you would benefit from some development operations processes, and possibly tooling.

You know, if you're spending a bunch of time you know, waiting on validations, or it's taking you forever to build your comparison or to build your, change set you know, there's things you can do to to help solve that. You know, if you're having regular deployment failures, a common thing that I that I would struggle with standard change sets is the the issue with dependencies and knowing what's dependent on, other what metadata types are dependent on other beta metadata types, So, there's tooling, that you can get that can that can help with that as well, which I'll talk about in just a second here.

And, you know, if you're additionally, you know, if you're spending hours setting up sandboxes with data, this is, like, a big time waster that DevOps can really solve, like, DevOps tooling, because, you know, relationships and and object relationships in Salesforce can be very complex. When you're doing an insert, and you need to, like, see the sandbox, so that users can have, like, valid data to test with.

It's it's it it can take a very long time. You have to, you know, like, you insert the account then you have to insert the contacts, you know, then you insert the opportunities, then you have maybe custom object relationships between those things. And sometimes, you know, you have to come back to an object that you just inserted to do an update to create the relationship between another object that you just inserted.

So, you know, it can be very costly and and take a lot of times, setting up a sandbox with seated data.

And in addition to that, you know, not everybody has is able to have a full copy of a sandbox.

And personally, I think they're kind of expensive and a waste of money. I think if you could just have a subset of data that is easily seeded into a sandbox environment. Like, that's that's the way to go and just have like a sample of of each type of data.

So, you know, things you can do to stop wasting so much time, deploying and spend more time developing would be, like, automating your deployments, So, many companies will start in a development sandbox, which is, like, will have a fresh copy of the org. And they will, build their changes, and then they'll do their QA testing and then deploy it to, like, a staging environment. And then once it's in a staging environment, you know, it'll get validated against prod, and you can have it all scheduled to release on a specific day. So you can now have, like, a release day where, you know, your, your, deployment tool on Thursday, is scheduled to run. And whatever is is up dated and changed in that environment can get pushed up to the, the environment above that. So it's saving you on having to do an additional, deployment. To the org.

You can also utilize deployment tools that speed up the process, you know, regular deployment failures. You have issues with dependencies. So there's tooling that will tell you, hey, if you're deploying this, you're also gonna need this. If you don't include it, your deployment's gonna fail. So it can save you a lot of time from having to go, you know, back to your change set at the dependency validate, you know, you can just make you know you have all the dependencies then and there, and you only have to validate that one time.

Additionally, like, there's there's tools for sandbox seating as well, and there's some really nice ones out there that will let you, you can, you know, take a cop take the data from production and push it to the sandbox. But if you're working with, like, maybe HIPAA compliant data or PII that you don't want other people to see that are gonna be in that environment, like a consulting partner, you can do, like, data masking, and, that will kind of, like, cover the PII side of things. So you can have partners like working in your org and developing without having to expose, sensitive data so sandbox eating is definitely like a big time saver and, highly recommend you, add that to your DevOps process.

Another thing you can do is validate early and often.

If you're working on a really large change a new feature, a new project that's going live, and it's, like, say it's due or it's go to go live as next month.

I would just go ahead and start validating, like, now, and make sure that, you know, you're not gonna hit any major roadblocks.

One of the very common ones I see when, people don't validate early and they wait till, like, literally the go live date to deploy is test classes, don't have enough code coverage. And that can be a real problem, in, you know, many companies, but consulting, it can be a serious issue because you know, that that developer might have written that code a year, not a year, a month ago, and now they're on another project thinking they're done with their their resource time is fully booked up. They're, you know, hundred percent utilized and they can't come back and work on it. So had you validated sooner, you would have known that that task test class didn't have enough code coverage, and you wouldn't be where you are right now. So definitely validate early and often.

And and lastly, I would highly recommend doing smaller and more frequent deployments.

So if you know, you have this new project that you're going live with. Maybe there's, like, four parts to it.

Maybe you can go live with one part first And then, you know, a couple of weeks later, go live with the second part, that's gonna make your deployment a lot smaller, a lot more likely to, to validate and pass. And it's also gonna have less impact on the business if something goes wrong because, you know, it's just gonna be that one small piece, whereas if you go live with everything all at once, there's gonna potentially be, you know, problems with each piece of it, and you're gonna be scrambling to to fix, you know, each and every one of them, because it's meant to be live right now. So, so if if Salesforce is a critical platform for the business, and and you're suffering from, you know, lengthy downtimes, and it's due to, like, you not having the ability to roll back deployments maybe you deployed something. It was a massive breaking change.

Nobody can use the system right now, and you didn't have version control. You didn't have data backups, maybe some automation overwrote a bunch of your data.

That's that's a very big sign that you need some DevOps processes and potentially tooling.

You you want to be able to easily deploy something. And if it screws up, I mean, there should be QA. There should be a QA process involved here. But in the event that, you know, QA fails for some reason and something gets by, you you need the ability to quickly roll back those deployments. So you need version control, or some some backup to to be able to roll back the metadata and to be able to do so quickly.

Because the longer that, you know, if if you've got forty many companies actually, like, use Salesforce as their, their main platform. Like, they don't have anything else. They do it all in Salesforce. And you know, if you've got forty or fifty people or more working in the org and you release some breaking change and and it makes the system unusable. I mean, Think about the cost that that is going to, have for not for having fifty or however many people are in your org, not able to work for, like, an entire day. I mean, just, like, think about the cost of that. What would that cost you and use that as ammo?

To to try to get buy in from the company to commit to some of these, develop DevOps processes and tooling.

Also the you know, there's a there's increased security risk when you don't have DevOps and Salesforce is a critical platform for you.

I've worked in orgs where, multiple companies work in the same org, and the sharing roles is, like, the only thing separating you know, like, a HIPAA compliance issue potentially.

And if you were to deploy, something that, like, broke the sharing rules. I mean, and and you didn't have, like, a peer review in your change approval board process. Nobody looked at it. Like, it's gonna fall on you. And it could have been potentially caught. So, you know, definitely if you're suffering or see the risk of any of these, at your company, you you should definitely be considering, DevOps.

Like, ultimately, all of this is gonna lead to team frustration, not having a dev ops process.

You're gonna have gonna suffer from loss of work, you're gonna suffer from rework, you know, losing metadata or having to redeploy page layouts, or, fixing automation that wasn't properly QA because QA is not part of your process, or the teams didn't have good test scripts and didn't QA it well enough, whatever it may be. You know, end users can't use the system. This this is all gonna come back on your team. You know, it's it's gonna look like the the development team is failing, and, they're they're not able to successful, and it it looks like a failure of their and it is.

I mean, if if you're suffering from these problems, the the solution is to incorporate process and get and pitch to the company to get the tooling that you need to to mitigate these these types of issues and save yourself time. You know, if you're having to to work weekends on bug fixes, constantly, You know, that's gonna stress out employees. They're not, you know, leadership, is is gonna fear go lives and end users, if if every time you guys are deploying something, it's, you know, something else breaks. Like, people are just not gonna want change.

They're you know, not gonna have faith in in the team, and they're they're not going to be on board for these new features, and, adoption is going to be lowered And on top of all of that, you know, a a stressed employee is not happy, and you'll end up having team team members leave because they just they don't wanna deal with the complexity of, you know, a convoluted process where everybody's deployments are are breaking everybody else's deployments. They'll just want to go potentially to somewhere simpler or some place that already has it figured out. So, that that can a huge huge problem.

It takes it takes a lot of time and money to to get new people trained up and, you know, think about the cost of that.

So where do I go from here? So this is just my high level recommendation of, you know, if I if you don't have a DevOps process, like, where do you start? I mean, I would just start with, like, your biggest weak points and potential risks. Like, where can you have the biggest impact?

Try to determine what tooling, would benefit that, do some comparisons. There's a lot of different tools out there that have, you know, many different features, maybe some are more beneficial to your, the way your team works than others. You know, it's not a one size fits all. You kinda have to figure out what what works for you.

And, I would determine, like, the cost and the ROI. So, like, what what not just the cost of the tooling, but, like, what is the cost if the company goes down for a day, you know. I I bet you a lot of companies, like, the tooling would pay for itself in one day, if the if they had it and prevented the the company from going down. So are the org from going down?

And and finally, once you've determined, like, your cost and ROI, like, what what what tools, what processes do I need, then, you know, try a call scheduled with, leadership, the the powers that be and present your case, and and, hopefully, you convince them to, to buy into it. If not, hopefully you can get some good feedback from them and and go back to the drawing board and, you know, fix up, your plan and and try again.

And then, lastly, just, you know, once you once you do get going, just start small. You don't want to try to implement a process for all of your development all at once because it's gonna lead to a lot of issues and things that aren't working. You kind of really need to start small and build your way up.

If you want this to work and you want to have good adoption, from from your development team, So that is my talk. Thank you everyone.

I hope you enjoyed it, and just one last slide here for the Salesforce Discord. We'd love to see you guys over there. And then, feel free to, connect with me on LinkedIn.

Oh, thanks everyone.