Description
Catch up on this webinar with Michael Halliwell (Salesforce Consultant at Growth Heroes) as he runs through a few general Devops tricks and Gearset tips that can help take your DevOps skill set to the next level.
This webinar covers:
- General DevOps tips
- Backup
- Disaster recovery
- Dark launches
- Gearset deployment tips
Learn more:
Related videos:
Transcript
Alright.
Hopefully, you guys can all see my screen here.
So today, I'm gonna be sharing just, really just some DevOps, some general DevOps tips, and, some of my favorite gear set tricks, that help me really, do my deployments faster.
So with that, I will do a little about me here. So, again, I'm Michael Hollowell. I'm a consultant Salesforce consultant, for Growth Heroes.
And, I've been, I've been involved for Salesforce for about seven years now, and I've been a moderator of the Salesforce Exchange Discord for about five years. If you're not familiar with the Salesforce, Exchange Discord, I'm just gonna do a quick plug on that. It's a it's an online community. It's a server that's hosted within the Discord application, and it's it's really just a great place to collaborate, with other admins, other devs.
It's great if you're trying to break into the industry and you need career advice advice or some resume help, or you're just like, what is Salesforce? Like, do I, do I, am I interested in this? Like, you could talk about all those things and it's a really good, it's a great, a great resource and a lot of really knowledgeable people, you know, from people that don't know what Salesforce is all the way to, you know, ten plus years, developers and admins and architects and things like that. So, if you're ever needing Salesforce assistance, definitely check us out.
I'll have a link at the end of my slides here.
Just a little bit other a little other few other things about me. You know, I'm just I'm passionate about helping others. That's why I'm in the Salesforce Discord all day long. I just love helping, people, you know, see that light bulb go off and, you know, teaching best practices and, and really just making, making lifelong friendships in the industry, which, I've I've made quite a few of. So shout out to the Salesforce Discord and Gear Sets in there as well, so you can come say hi there. Come say hi to them there. So for our agenda for the day, it's, we're gonna be going over just some general DevOps tips, for backups, disaster recovery, and dark launches.
And these are sort of just some, just some random tips that I I thought would be good to share. It's not like an inclusive, like, how to set up automated backups or how to do your disaster recovery or, you know, the it's it's really just some tips, for each topic. So I'll be sharing those. And then after we get through those tips, I'll be doing a live, Gearset deployment. Not a deployment, but just a comparison to show you some of my tips and tricks, and how I use Gearset.
So kicking things off, we'll start with our general DevOps tips.
So we're gonna start with backups. Again, this isn't like how to implement backups or an all inclusive guide on what you should do for backups. It's just some tips, around backups.
And, you know, every Salesforce org should should be getting backed up. If you're not backing up your org, you are, you're just asking for trouble.
You should you know, there's a lot of reasons why you should back up your systems, but I think the main was main one is, you know, if if, you know, some disaster occurs and all your data is corrupted or your your, your Salesforce org gets corrupted, you wanna be able to restore from a backup. So it's gonna protect your systems, in the event that, you know, something blows up. And it's also gonna you know, you wanna guarantee that you have the most up to date data possible with your backups.
So if you, say you just do monthly backups and you do a backup on the first of the month, and now it's the thirtieth or the last day of the month, and there's some integration failure that wipes out a bunch of data, like, maybe it cleans out all your account data or your opportunity data, you know, whatever it might be.
If you don't have an up to date backup, it's gonna create a lot of problems, not just for your end users, but your company in general.
So for example, if you have a sales rep who's making his daily calls, he or she's making their daily calls, and they're they're creating their contacts in Salesforce, they're generating their opportunities, they're logging their tasks, and they're doing that for an entire month. And on the last day of the month, you know, something fails and they've lost all that data, that sales rep's gonna be pretty upset.
Not just because, you know, well, a, they they feel like they should be able to trust Salesforce. We've trained them, you know, oh, take that business card, put it into Salesforce, and then throw the business card in the trash. You don't need that anymore. Well, that's only the case if you have good backups.
And on top of that, you know, it affects the company whereas if if if a sales rep is logging these opportunities and the opportunities are deleted and he doesn't know, you know, what opportunities, who they were logged with, you know, what were they interested in, it's gonna make a bad impression on the customer, and then you're potentially losing revenue, as a company as well, since you're not gonna be able to get that opportunity data back. So, having having up to date backups, preferably daily is is definitely recommended.
And another benefit of automating your backups is gonna be that it's gonna give time back to your implementation team, which I think is huge. You know, when you're if you're spending a bunch of time, you know, exporting a hundred different objects, It's it's just not a good use of of, you know, the implementation team's time. They could be spending that time working on new features, better supporting the end users, things like that. And it's it's just not an effective use of time to be doing something that could easily be automated. So, that's definitely a a huge reason to to automate.
Along with automation, you wanna make sure you're backing up your metadata and your actual data. So if you're new to Salesforce, metadata is like your configuration, of Salesforce. It's like it describes what is, what objects you have, like account, contact, and and then, like, what the fields are, within those objects. And then, also, it's gonna describe, like, who has access to those objects, like your permissions and your permission sets. And if that gets wiped out, you're gonna have a bad time. And you need to back up both your metadata and your data because they're really relying on each other.
If the metadata configuration gets corrupted, there's no place to put your data. And if you don't have any data, well, then your metadata configuration is useless.
So, really, it's it's crucial that you back up, both your data and your metadata.
And for your metadata, you really want to be using version control, which Jack, more elegantly described earlier.
But, basically, like, the the basics of version control is if you have, say, you know, ten devs working on an Apex class, and they're all working within that same class and making changes, if one of them makes a breaking change and that makes its way up to production, you're gonna want that history of changes so that you're able to revert back to that last working bit of code, get that back into production, and then start working from from, you know, that previous version of the code to try to make the changes again that you were originally trying to make. So it's really, you wanna have that history of changes so that you can audit, the changes and then ultimately restore, from, you know, a good a good backup. So version control is definitely crucial.
And then when it comes to backups, like, consistency and accuracy are probably two of the most important things when it comes to backups. If you're, you know, if you're not consistent with your backups, they're gonna get out of date. And if they're not accurate, there's no point in even having a backup.
So, you know, manual backups, if an admin's doing a manual backup once a week, once a month, it doesn't con guarantee consistency.
They can go on vacation. They can get sick.
There can be an issue where, you know, a critical issue comes up, and they were originally planning on doing a backup today, but now they can't because they have to handle some, high priority issue. So and maybe they won't get back to it for another week, and if something bad happens in the meantime, again, like, your your data's gonna be really out of sync, and you're gonna have a lot of pain to deal with. And then, you know, on top of that, manual backups are also prone to mistakes.
So, for example, I know personally, I've I've done data loader backups, and I've literally I meant to select all all columns, and I've I've just selected the ID column. And so my backup is just a a list of IDs, and that didn't do me any good and was extremely painful to to try to fix that and had a lot of people upset with me. So, you know, manual backups are are definitely prone to mistakes, and I would definitely automate and and try to avoid that.
So I do think, backups plays, kind of well right into disaster recovery.
So, you know, why do we need disaster recovery? I mean, at its base form, it's because if things go awry, if something blows up, you want to have a plan. I think that's pretty obvious. Like, you know, what what do I do in this situation?
So I think that's the biggest reason. But on top of that, you know, you you really want to and I will I will say that some people say that disaster recovery isn't really a part of DevOps, but I think it really is because your your DevOps process is really gonna support your disaster recovery. So I think it's it is a pretty key piece of this. But, yeah, it's gonna limit your your downtime, which is definitely the ultimate goal here is we wanna get the system back up and running as soon as possible.
Some people that use some departments that use Salesforce, they solely work in Salesforce.
And if that system is down, they can't do their job. So, you know, queues are getting backed up. Work is getting left undone.
Money's getting spent on paying employees who can't do their job, and it's it's just bad. So you wanna limit that downtime as much as possible and get the org or whatever system it is back up and running ASAP. It's also great to to know who is responsible in the event of a disaster.
Who do I talk to? Who's gonna handle communication?
Who's gonna escalate? Who's actually gonna do the restoration of the failed system?
So it's it's really helpful in that regard. And then, of course, compliance, you know, for SOC audits and you need to have a disaster recovery plan in order to to get your SOC compliance. So it's it's sort of an obvious reason, but, really, it's like you should just have one anyways because it's it's not gonna be fun if you don't have a disaster recovery plan and disaster hits. I think people that have dealt with permageddon in the past, would agree with you or would agree with me. So, we also have just another tip around disaster recovery is, you know, setting up a good disaster response process.
So some tips here would be, like, set up preconfigured email groups.
So if, you know, say you're the one that's responsible for communication to letting everybody know, like, that there's an issue.
If you have preconfigured email groups with the departments or teams that are related to the certain features or or certain systems, it's gonna be a lot easier to outreach to them, to let them know that there's a problem and that you're aware and that you're working on it, as opposed to, you know, going into your Outlook address book and searching for ten different contacts to add to an email and trying to decide if John Betty one is the right one or if John Betty two is the right one to email. So definitely set up your preconfigured email groups.
And then also, single point of communication.
Having a single point of communication is is really best practice, when it comes to disaster response.
You know, you want one person to to really, do this outreach so that emails aren't flying back and forth and things are getting confused and and and whatnot. And it'll also help, you know, give an official response to an influx of tickets. So if people are, like, freaking out, send in ten tickets in a, an hour, you know, the system's down. It's like you wanna get that single point of communication.
You wanna have them email out and let them know that, hey. We're working on it. Everything's gonna be okay. And a great example of this is with Permageddon.
If you if any of you recall, Permageddon was basically Salesforce released an update, to many orgs that had Pardot installed at one time, or currently, and essentially gave, full access to the entire orgs to all users even if they had, like, a read only permission.
So when that happened, Salesforce, you know, started these webinars, and they had a single point of communication, which was Walter. I think a lot of people might remember him. But, so it's sort of like what would Walter do is my acronym here. And, he was sort of that single point of communication, holding our hands, telling us everything's gonna be okay. And, so I think that's just a great example. And then also with your disaster response, having communication templates is is really key. You wanna have clear, concise communication, like predefined when this type of system goes down.
You know, what type of how do we send this email? What does it look like? And because ultimately, you want the end users to feel, like, secure and safe and and feel like, you know, you're taking care of the issue. So I think communication templates are are really huge for that. Finally, with disaster recovery is gonna be just practice.
Your your backups are useless, unless unless you practice restoring from them. You may feel really great, like, you've oh, I just set up this automated backup. I I've added all these objects. Well, maybe you forgot a a lookup, column, you know, on one of the objects.
And now when you are trying to restore from that backup because something bad has happened, now you're not able to do a full restore because you forgot to pull some some object that this lookup is looking up to. So that's gonna be a bet a big problem. So you definitely want to practice restoring from your backups and not just your metadata or not just your data, but also with your metadata. Like, make sure, hey.
Can I pull this org back from the grave if it blows up tomorrow? You know, that's something you wanna be able to say yes to.
And then, you know, same with your communication systems. We're talking about disaster response up here. You practice your responses. You know, make sure the email templates that you're creating make sense. And if there's merge fields that the the merge fields are populating correctly, you know, you don't want to send out broken emails and and emails to people that aren't relevant or no longer at the company. So definitely, practice your disaster response.
Okay. So that's gonna bring us to dark launches.
This is, again, just a a general DevOps tip. It's something that I like to do in a lot of my implementations.
Sometimes, you know, it's and and really what all the dark launch is is it's it's taking a feature that is maybe potentially ready to release, putting it in production, and then just releasing it to a subset of users. And this is really helpful, for a multitude of reasons, and you can do it a multitude of ways. Like, you can do it with, like, permission sets, permission set groups, or, like, dynamic visibility, on the lightning record page is is one of the the ways that I like to do it, which I'll touch on here in just a second. But it's really it's really just a way to get it in the hands, deploy this thing to production, get it in the hands of a subset of users so they can kind of filter through things, weed out the bug the bugs.
And, and what that allows for is really, faster feedback. You know, a lot of users don't like going into the sandbox. It's, you know, an extra step for them. It's a different it's a different login, and it can be kind of confusing.
And on top of that, some features really kind of require a lot more data to to really see if it's working right. And a lot of companies don't have a full sandbox and can't afford, you know, a full copy of their production org. So sometimes it's it just makes more sense to to get that thing into production so that they can work with, some real data. But, again, just releasing it to a subset of users.
And and so the benefits you know, there's a lot of benefits. One of the benefits there is they can they can get the the power users, the people that you release this to, they can work through, you know, some of the the issues, figure out the bugs, the kinks, and we can take those back to the sandbox and and fix them up and then, you know, deploy again. And then once they're good with it, then we can do, like, a a rollout to maybe the rest of the company, if we're feeling comfortable. And so that that really reduces risk, because you're not potentially releasing an unfinished product to the entire company, which would, you know, reduce trust in their ability for the Salesforce team to build things, which is never good.
So it's it really is helpful in reducing risk and getting helps get a a better cleaner product to all of the end users by just sort of exposing it to a subset for a period of time.
You know, feature enablement when it comes with dark, when it comes to dark launches. Salesforce, I think, is is really cool when it because you can do, like, your permission set access, which can be added to permission set groups. So if you want to enable a feature for somebody, you know, you can add all your permission sets for that app, whatever you've built into a group, and then you can just assign that one permission set group to an individual or to to multiple users.
And it's really just gonna speed things up and, you know, let you roll this thing out, really, really quickly once you're ready to.
K. So this brings us to the Gear Set deployment tips live demo.
So for this, let me pull up my comparison, and hopefully, you guys can all see that still.
So I'm gonna start off with some light tips and then kind of go into slightly heavier, tips on on how I use Gearset to, you know, make fast deployments, do do faster deployments and really try to be efficient and make the most of my time when I'm using it. So to start off with, I'll go into, the comparison filters here.
Whenever I'm starting a deployment, I usually always have a deployment list, so I know what I'm going to be grabbing from these sections. But sometimes there's sort of some caching things going on, and I just like to select everything and then deselect everything. And that's how I know I've got a fresh, clean list to start from so that I'm only taking the metadata types that I really need. And it's important that you only grab the metadata types that you really need because of speed.
If you grab I I've seen so many times people just litter Looks like we've just lost the audio slightly on there, Michael. I'm I'm back. Sorry about that. My headset back.
Problem.
Sorry about that.
So yeah. So I've seen so many times people will select all here and then just compare the entire org. And not only does that take forever, but when you actually get to your comparison screen, you have to sift through all of these extra metadata types that are just completely irrelevant.
So definitely, you know, just take what you need here. On top of that, I really like the, let me select a couple of here. So I've got two things selected. I'm a big fan of the selected only drop down, and it'll just show you what you have selected, and you can easily kinda sift through and add or remove items and just make sure that you've got everything that you need selected.
Another quick tip is gonna be the change by column here. I this is really helpful if you're coming into, like, a new org or, you know, maybe an org where you're a new admin, last admin's just left, and you can you know, or it's just been a very long term build and you don't remember what is yours or not. Hopefully, you're keeping track of those types of things. But if you ever run into a situation where you're not really sure if something was your work or someone else's work, this changed by column can be super helpful. Unfortunately, I don't think all of the metadata types in Salesforce, or something something with the Salesforce meta types, they don't always give it to you, but it can be really helpful. I'm also a big fan of using these filters up here, to, you know, narrow it down. If I've got a lot of stuff that I'm trying to sift through, you can come into your metadata type filters and and just kinda filter down to what you wanna look at.
Also so when it comes to selecting your metadata I can't see this, though. Because I have a filter.
So when it comes to, like, the actual comparisons, Gearset has added some really, really cool features lately.
So we can look at, like, the account layouts here. And so you can see that they've added, like, this layout view. It used to just be XML that you had to compare and then and try to sort of discern what the heck's going on, but they've added this layout view, which is super, super cool. So you've got these, different layout sections.
So this is literally your page layout, like, in the source org and your page layout and the target org. And you can come in and you can, like, uncheck. So, like, we can see that industry and annual revenue was moved down, in the, target org. So you can actually say, like, you know what?
I like industry and annual revenue where it's at in prod. So, I'm just gonna uncheck I'm gonna uncheck these options, and so it's gonna leave the industry and annual annual revenue where it's at. So this is just really helpful, a, for not overriding changes that are probably like, like, that shouldn't be overwritten. And then, b, it's, it's really good, like, if you accidentally add a field to a layout that you don't need to send to the target org, you could just uncheck it, and and continue on with your deployment.
You probably should go back and still fix that layout in the in the source org, but at least you can, you know, move on with your deployment and don't have to go back.
They also do this with, pick list in a similar manner, which is pretty cool. So we can see in my source org, I've got two two values for my pick list drop down down here. I've got active and inactive. And then in the prod environment, I've got active and terminated.
So right now, if I were to just, deploy this, you know, it would I could I could delete terminated by checking here, and, I can include or exclude this different, inactive value. So you can add these or remove them, in the deployment, which is really nice. You know, you're not having to, like, go back to the source org and deactivate or delete pick list values. You can kinda just manage it here, if needed.
So a really big fan of that feature.
On top of that, one of my favorite features is gonna be this refresh item. So, I'll show you here. So we've got active and inactive in our source org.
I'm going to do a dangerous thing and try to do this live here.
So I've added a value of pending to my status field, in the source org. And so what you can do is you can select account dot status, your meta custom metadata type here, and you can just hit refresh item.
And we'll just give that a sec.
And you can see that it's refreshing the comparison, but it's only doing it for that one individual, metadata type.
So and and and where this becomes beneficial is, like, a lot of times if you add a value like that and you, you know, you have to refresh the entire the entire comparison. And so this, like, just saves a lot of time. So we can see now that it's finished refreshing, and my new option of pending is here, and so I can include that in the deployment.
So super cool feature there.
One other thing I wanted to share with y'all is, when it comes to, like, don't, don't don't throw hate in the chat here. I've got a workflow alert. It's just an email alert. I know these things are being deprecated, but it was just an easy way to show, these environment variables. So we can see on this workflow alert, it's assigned to myself, well, a user, with the ending in, you know, DevOps test org one here.
If I try to validate this, gear sets problem analysis is gonna tell me, like, hey. This isn't a good idea because it references users that might not exist in the target org. But what I've done is I've set up an environment variable, and what that does is it takes the user that it's assigned to and it's replaces it in the metadata with the user that you provide. So when I go to validate this, it'll actually validate because it's replacing my, sandbox username with the prod username.
And this is just such a huge win. I think it was one of the most upvoted ideas on the Gear Set IdeaExchange, which is probably the wrong terminology for what it's called. But, that's basically what it is. And, it was the most upvoted idea, and and everybody was asking for inline editing of metadata. But I think this is really, like, a better solution because you can, you know, set it up so that they can be reused.
You don't have to just go do another org, grab the user, export the metadata, change the user, upload the metadata, deploy. It's it's just a really, really great feature.
And then finally, one last thing I wanted to show y'all, which I didn't really have a great example set up, but I just wanted to point it out.
So let's say I'm in the middle of a comparison right now, and I find that the name of my object, like, has a typo or something.
So say I've got a custom object and I go into Salesforce and I rename that object.
Well, you're not going to be able to pull that object in with just a refresh. You kinda have to start the whole comparison over again. Gearset, correct me if I'm wrong there, but I think you would. But what they have done and I don't I'm not sure how long this has been around, but I recently figured it out or realized it. But if you, like, change the name or add an object or or something in the middle of your comparison, you can just come to whatever metadata type it is that you changed or added, and you can just add it here. So, like, if I change the object API name, I could just, you know, type in new object underscore underscore c and add it, and then that will actually, come into your comparison when you do your comparison.
So, yeah, hopefully, you guys, enjoyed some of those tips. Hopefully, you guys learned a little something.
I appreciate y'all listening in and taking the time to, check out my talk. So appreciate it y'all.
And then, again, if, I think they'll probably be sending out the slide decks, but this is the link to the Salesforce Discord Exchange, if you guys would like to join and my LinkedIn and then, the URL for, my company growth heroes here. So thank you very much.
