Gearset Accelerator – Compare & Deploy

Share with

Transcript

Started with, so we'll jump straight in. So hello, and welcome to our first entry into our new accelerator webinar series at Gearset. So to kick start, today, Maroof and I, we're gonna show you how to use our compare and deploy functionality, compare now. So, Maroof, we'll show you around a twenty minute demo into how this functionality works in order for you folks to become more confident and comfortable with deploying this data within Gearset.

So by the end of today's session, you'll know how to compare and deploy metadata quicker, how you can get full visibility into your orgs and source control, and how Gearset's problem analyzer tool boosts your deployment success rate too.

Regarding questions, there isn't a formal process, but we have dedicated time at the end, for questions. But if we're able to answer them on the way through, we will.

So with that being said, I will leave you in the capable hands of Maroof. The floor is yours.

Thank you very much, Beth. And, it's great to see you folks here, so thank you for joining. I guess I'll start off by sharing my screen so we can dive straight into Gearset.

Beth, could you just confirm for me very shortly? We hoping hoping you can all see my screen.

We can indeed.

Fantastic. So let's get going. So, folks, as Beth mentioned, we're gonna be showing you our compare and deploy tool. For those of you who are not familiar with Gearset or this is your first time, Gearset allows you to pick a source and a target and, run a comparison between them and make deployments between them.

The stores and target is a fundamental concept in everything you can do within GSM, whether that be org to org deployments, introducing version control, and even when it comes to the migration of businesses' Salesforce data's data. So these are all topics we're gonna be going on to cover over the course of this series. But in today's example, we're gonna be showing an org to org comparison and subsequent deployment to follow. So let's set this in. I've picked up a Jira ticket, and it's a cluster of changes that are ready to be moved from my, developer environment into my UAT for testing. So I can go ahead and start picking up the environments. So there's my dev in the source and my UAT.

Now that I've got these there, I just simply hit compare now.

What this has built up now is essentially a blank canvas where we can start to pick out what metadata types we want to compare.

We can pick from this bar down here along the left hand side, or we can search for specific metadata types such as custom fields.

Now my team and I, we actually we make very similar changes most of the time. So we have presaved filters, and we'd use these as these cluster together, all the metadata types that we're going to need as part of our, comparisons.

On this particular occasion, we have actually decided to add another type. So So we've done a flow, which we don't usually change. But for today's demo, I've decided to include a flow. And you can see I can quickly search for the metadata type and add it to my filter.

We can further refine these filters if we need to just by clicking this button up here.

And here, we can search for a specific named item.

We can search by API version or choose to include or exclude managed packages.

And, also, this is the screen where we can save these for later as me and the team have done. So you can see it here that I can add this as a new, new filter, save it for later, and also share with the team.

So now back to our comparison page.

So now that we've selected all metadata types, we can start to look at, you know, how they appear in our source versus our target.

All the components based on the items we've picked up will be listed across here. And in the bottom half of the screen, you'll see how they appear in our source environment and our target environment.

Finally, along the top, there's a further refine a further way to refine, I guess, what we're gonna be picking up. So you can see all items. This will show everything across both source and target. We've got new, which will show items that are in our source but not in our target.

We have changed, which is items that are in both, but there are some changes. And finally, deleted. Now deleted will show us items that are available in our target but not available in our source. And using Gearset, by selecting a deleted item, we can actually create disruptive changes to our target environment. So let's start to build out our package for deployment today.

We'll start off with custom object.

So here, you can see all my custom objects are listed up. Now I know the one that I'm after, and I know it's new completely brand new, so I can refine by going into new. Now I could choose to try and pick it up from here, but I can also use the global search function here. So in this scenario, webinar attendee is the custom field that we want to deploy.

So I can go ahead search for it, and it's come up there.

Now by clicking on this, I've selected this, and you can see how it appears in my source and how that it's not present in my target. So this is the deployment we wanna make.

You'll also notice there's a drop down bar here. Now if I click into that, what you'll see is Gearset's already picking up some dependencies, items that it's used by, excuse me, and profiles and permissions.

So if I take a closer look into this, you'll see all the layouts that are associated.

Now interesting thing with layouts is we can actually be very granular about how we, migrate those. You'll see I've got the option to see the layout before I even deploy this.

I'm gonna leave this blank for now and then move on to the profiles and permissions I mentioned. And here, you can see all the different profiles that are associated with this.

Now human error can easily happen. So for the purpose of this demo, I'm gonna choose to ignore all of these use by and profile and and permissions that Geosat has warned me about. I could select them by just clicking here, but I'm gonna leave them blank because I wanna show you how Gearset will handle this.

Now that we've got our custom objects, let's start looking at Apex class.

If I head over to Apex class, the Apex class that I'm gonna be changing today is one that I've changed. I've made some changes, I've made some changes to it, so I know I can find it under this section. And there it is right there.

So you can see here the account subscription number class.

What we are looking at right now in the, difference viewer is how it appears in our source and how it appears in the target. So you can see here that I've changed everything to reflect the length from not exceeding eight to not exceeding seven.

Now I wanna migrate this change. So the easiest way for me to do so is by clicking this tab here, and I select all the components, all the lines and everything to do with the change items.

However, you'll notice that I've got an option to be quite grand I've got the option to be quite grandiou about my selection.

So here, if I choose to, I can, decide to deploy specific lines or select entire blocks at a time. Now for the purpose of this demo, for this particular Apex class to work, I need to deploy all of it and delete these changes. So I'm gonna leave them as they are.

And then finally, I mentioned earlier that we have been working on a flow. So if I head over to flows, you can see this new flow. Now the typical kind of view for it is right here in our XML view, which is great. It tells us a bit. However, you've already got a sneak preview into this, so no surprises what's about to happen now. But if I click on the flow navigator, you'll see all the components of our flow laid out for a real visual prompt so I can see what's happening.

You'll also notice above each of these components here, there's a green plus, and that's to kind of reflect the new, icon that we see at the top.

If I were to go and edit this, or deploy this and then edit, then you'll start to see changed or deleted based on what I'm doing. So Gearset is allowing us to have a real good look at how the flow works, what's changed, what's new, and who doesn't love a visual prompt?

So I'm ready to deploy this, so I'm gonna go ahead and select this as a whole component.

So now that I've picked out everything that I want to deploy today, I can easily go and take a look by select, by selecting the selected items right at the top here. By clicking into this, I'll be able to see everything that I've included.

Again, all the dependencies are here. We'll deal with that shortly. But you can see the Apex class, the custom field, and the flow that I've decided to include as part of my of my deployment today.

If I need to add any more or take a look at the comparison, I can easily switch between by clicking comparison, and that will open everything that I've chosen to compare today.

Now say for whatever reason, while I'm making this deployment, I know there's some changes that have happened, Or I need to check, you know, has anyone made any changes that I'm not aware of while I've been creating this package? Well, if I suspect anything or I'm not sure, I can choose to refresh the entire deployment by clicking this button here. Or let's say I know a colleague of mine is working on a very specific problem or a very specific, Apex trigger, let's say. I can choose to refresh just that type, and GSM will run a quick analysis that shouldn't take too long on there we go. It's returned already. I can see nothing's changed, nothing new new since, I've built this package out. Out.

So that's our deployment built.

Now let's say I need to come back to this later. Something's popped up. I can always save this as a draft deployment to come back to later on. Once I've saved the draft deployment, given it a name, I will find it in this top section here under park draft deployments to return to when I see fit.

But we're good to carry on today. We've got plenty of time, so let's, move forward with this.

Now by hitting next, what's happening now is Gearset is running a set of due diligence on our behalf. So So as you can see, Gearset has given us a helping helping hand in this problem analyzer page. And the aim here is to help increase, I guess, the success rate of, of the of our deployments. So for example, here under, issues and automatic fixes, let's take a look inside.

We've got, would you look at that? Those items that I chose not to pick, as part of my custom, as part of my custom field. You can see all the missing components, and Gearset has given me a chance to include these.

Slightly below that, you'll see all those profiles and permissions that I ignored. And, again, has given me the chance to correct this mistake, and flagging to me that this might be important in my, deployment. So I'm gonna go ahead, trust key assert, and head back to the summary page now that I've got my automatic issues.

As we're also deploying Apex classes, you can see that in the code quality and improvements area, Gearset is going to give me a commentary on the quality of this code. Now this is based off the PMD library. Now you can customize this rule set on, your account settings here.

And let's say if you want to focus on a very specific area within code quality, let's say security, for example.

Excuse me. Or documentation.

And then you can do so here.

Right. Now I'm happy with that, so let's move forward to the next pitch.

So now we're at the pre deployment summary. Once we have gone through those extra due diligence checks, thanks to Gearset, we can see a full summary of everything we will, we're going to attempt to deploy.

Gearset also gives us a few options here just to make sure we've got some good practice and housekeeping, in order.

So let's start by giving this deployment a friendly name.

The webinar deployment just for the time being. And I can add some notes. So components or Demo to.

I can add some notes here. And this way, my team and everyone that needs access to this can see exactly what's going on in in this deployment.

Speaking of due diligence, wouldn't it be great if I could associate this to the Jira ticket that I picked up in the first instance? Well, good thing with GSA, you can. By clicking issue trick under issue tracking, by clicking the Jira updates, I can choose the relevant project and the associated ticket, and I can move this along where it needs to be. So I've already preset this to, in progress at the moment because I'm working on it, and I can set this to done. And you can set that up however best suits you in your workflow.

Awesome. So now we've gone through. I'm really, really confident when it comes to, you know, the success rate of this deployment.

Guess that's given me some due diligence. I know what I need to, what I need to deploy, and I've got the whole list, and everything's there. I'm feeling super confident. However, I've got two options here. So I can go ahead and deploy now.

I can schedule the deployment for later. Or as a final layer, just to check against the target environment, can run a validation on my behalf through, through Salesforce. So let's do that.

Okay. So now Gearset is starting to run a validation.

Now this is referencing against the target environment in this scenario over UAT.

And once this comes back, it'll tell me whether this valid this kind of deployment is likely to succeed or not.

This is kind of like that final green light that has just popped up. So now I know there's a really good chance of this being successful. So with that confidence, I've got two options now. But before I get onto that, I just wanna bring your attention to this page up here or this click right here.

So that's validated packages. Now that we've validated this package, that's gonna be available for us to come back to a later date if you want. So for whatever reason, again, you need to go away, do something else, you can always come back to validated packages, and this package will be ready for us to deploy. Having already been validated against the target, and it's kind of there at your disposal.

Awesome. Again, we've got time today, so let's move straight on ahead. Now, again, I've got two options here. So firstly, I can deploy now, which we're gonna do very shortly.

But let's say this was going to a production environment, and I don't want to disrupt the flow of any of my colleagues or any of the end users. So what if we could schedule this for a time that's more convenient, won't disrupt any flows? Well, we can do that. By scheduling a deployment, we can choose a time that suits, ideally, when none of our end users will be using, Salesforce, and we can set it to a time and set up the relevant, notification settings that work for us.

Today's scenario, we're happy to go forward with this UAT environment.

It's not gonna affect anything, so we can just go ahead and deploy now.

Final prompt just to say, you happy?

Yep. I'm good with that. Let's go.

So while that's taking place, let's just do a quick recap recap of what we've done so far. So first of all, we picked up a Jira ticket.

Now, Jeremy jumped onto GIS, we picked up our source and our target. We've run a comparison, on the metadata types that we know have been impacted.

Using that comparison tool, we've picked out all of our new and changed items with full visibility of what we're about to affect in our target environment.

We've run some due diligence and checks in the background.

And, we've also documented all of our efforts and tied to the relevant Jira ticket we picked up in the first place. And just like that, we've got a successful deployment.

So on this page here, we have a quick summary of of the deployment itself. Now I can go in and have a look at all the components that have been deployed, some other data like how long it took, all the relevant tags that we've put in here. And, this is you know, this will also in my instance, I've got this set up to send me a email notification, so this will be available to me there as well.

So there we go. So we've gone through the process of running that comparison all the way through to deploying those changes.

Now let's talk about some post deployment steps. In an ideal world, the testing has gone great, and we can push these changes straight through to our production environment. However, we all know this isn't always the case. Perhaps we need to start over again.

Maybe the changes aren't ready or they've failed at testing. Well, either way, Gearset can handle the next steps in just a few clicks. I've already touched on some checkpoints that Gearset has created for us along this journey. We've touched on the draft deployment and the validated packages.

We've also got one for the post deployment steps, and that can be found through our deployment history.

So So if I head over to deployment history, you will see a list of all the deployments that my team has made. And the most recent is the one that we've just walked through today. So that's from our dev environment to our UAT.

So we've got a few options here. So let's start with the worst case scenario.

Items haven't worked, and we need to kinda go back. Well, rather than going through that entire process to reverse that change, what if we can just use this as the template?

By clicking rollback, we can start a rollback comparison, which will essentially help us revert the, revert that target environment to how it was before. So what's happening right now? Let's break this down.

Right now, Gearset has kept a cached version of our target environment about two or three minutes ago prior to us making that deployment.

So now this comparison, you'll notice that the source and the target, the same environment.

The target is the environment as it is now post deployment, and the source is the environment, let's say, five minutes ago before we made any changes.

With using this cached version, Gearset is now comparing the two environments so that we can, revert to its original state.

While that's taking place, This might take a little while to cash. So, Beth, if there's any questions, now might be a good time.

Of course. We have just had one. Just going to that problem analyzers page. Someone asked, do we have to listen to what the problem analyzers that Gearset suggests to us?

Good question.

You don't have to. You, you know, you can ignore them.

There is a chance that the deployment could, you know, still be successful without, you know, listening to everything in that problem analyzer. But as I mentioned, the PA is there to act as recommendations for what to include, remove, or edit.

And and the goal there is to help with the, I guess, the success rate of your deployments. So, again, you may know our your orgs better than we do.

But Garett will always provide you suggestions, and you can choose to disregard if there's something you know.

Awesome. Thanks, Ruth.

No problem at all.

Awesome. Just like that. So we're back to this comparison. So we're in the process of rolling back a change.

So as I mentioned, we're now gonna be reverting the deployment that we've just done. So, essentially, you can see here all the components that we picked out as part of, our deployment. They're all there for us to have a look at. In this particular scenario, the, testing in UAT has failed, so we need to restore UAT back to its original state and go back to the drawing board.

As I mentioned, just two clicks away through the rollback, we're back at this page so that we can follow the steps and revert the changes we've made. Now I can choose to roll back the entire deployment, or I can be very granular about this and just pick selected components if I know let's say, for example, it was just the Apex class that worked and everything else didn't, then I can deselect everything else and keep the Apex class, for example.

After that, the process going next, is exactly the same as what we've gone through before. And just like that, we can roll back without having to start from the very beginning.

So that's worst case scenario.

Let's talk about the scenario what we all hope for and pray for is the testing's gone beautifully well, and we're ready to push these into, production. Well, once again, a very similar step. So instead of rollback, this time, we can you go to that same, deployment in our deployment history and click deploy to target.

This time around, we skipped a whole bunch of steps through that comparison because everything's ready, and we know what we want to deploy. All we have to do now is update the notes accordingly and choose the target. So in this case, I can go ahead and pick my production environment.

I can also update the Jira ticket if I need to as the same way as I showed before.

And, again, same. Deploy now, validate. Same process as last time. You just follow that workflow along. And, like I said, just a few clicks away from the next environment or rolling back if you need to.

So with that, that's everything I had to kinda show you today. So, you know, I I hope this gives you folks the confidence to jump into Gearset, run some comparisons, and start deploying your changes.

However, if you're doing encounter any issues, then please do not hesitate to reach out to our team of support engineers.

You can do so by using this in app chat button down in the bottom right hand corner. Through messages, you can, chat with one of the team. Or if you're looking for any specific guidance, you can just search. So for example, someone asked about what was the question we just had? Problem analyzers?

Yeah.

There we go.

Can search for a whole heap. Whatever it is, the issue, likely, we've got a documentation for it, and you can search that all here through this little button in the corner.

With that, I will stop sharing my screen and hand over back to you, Beth.

Awesome. Thanks, Ruth. Just got two more questions as well before we finish. So a really fun one is can you roll back a rollback?

It's, it's quite interesting how often we actually get that one. The answer the answer is yes. Absolutely. Yes. It's exactly the same process. It will be available in your deployment history, and you can choose to roll back.

Fabulous.

And the last one we had, someone saw that within your the metadata filter, that you can pick and choose. So it was a a source tracking, feature. So I was asking, how how does that work?

That is a really good question.

I guess, firstly, for anyone who hasn't come across this, I'll just start with a quick explanation. So Gearset uses some native source tracking functionality that's available in your Salesforce orgs to automatically build a comparison filter showing you how your orgs have changed. It removes the need to spend time customizing a comparison filter, like, manually, and instead, it enables Gearset to immediately create it for you based on the source tracking information from your org.

So that's the kind of overview.

In terms of how to use it, again, the answer is very short and quick, but, yes, you can. To enable source tracking, you need to first enable it in your production org, and any existing developer or developer pro sandboxes will need to be refreshed in order for you to make the most of source tracking within Gearset.

Perfect. And that's amazing, Ruth. Again, if if there is any questions or anything related to that, we have plenty of articles like Maroof shown, on our kind of website.

But if not, you can always reach out in chat and they'll direct you to the right place.

So with that, thank you so much, Maroof. That was amazing. Really, really thorough.

And, hopefully, by now, folks, you'll be confident with using our compare now functionality, with being able to deploy metadata between a source and target, whether it be source, be it, sorry, an org or version control, however it may be.

Also knowing how our problem analyzers work and how it kinda boosts your deployment success rate, and also how you can take control of when and where your deployment package goes, by who. So if you have any outstanding questions, any at all, then please feel free to email us at success at Gearset dot com. Or, again, you can open one of our in app chats and chat with our team there. So with that being said, we thank you so much for joining us, and we'll see you again for the next webinar series.