Gearset live: a look at Gearset Pipelines

Share with

Description

Enjoy this session of Gearset Live with Jack McCurdy (Salesforce DevOps Advocate at Gearset) and Jeb Garrott (Platform Solutions Manager at Morgan & Morgan) as they showcase Gearset Pipelines, a management and visualization solution for your Salesforce release pipeline.

Jack and Jeb discuss:

  • What a basic org to org deployment looks like with Gearset
  • The flexibility Gearset CI jobs offer for different branching strategies
  • How Pipelines works with a Git first model

Learn more:

Related videos:

Transcript

Body welcome to, this edition of gearset live. I am super excited to bring you this session today, which I do not do alone. So I am joined here by my My good friend from Morgan and Morgan, Jeff Garrett. Jeff, hi.

How are you doing? Good. Doing well. How are you how are you doing today? Yes.

I am fantastic.

We are getting going here, Jeb, and, today we are gonna be taking a look at gear sets pipelines, functionality.

So gear sets, for those of you, on the webinar that may may not already know GIRSA is, the full all in one, DevOps solution for Salesforce professionals. So We have a large suite of deployment tooling to help with help with releases of your Salesforce metadata, your data, making sure it's all backed up. And being able to help introduce automated Salesforce delivery into your Salesforce development workflow.

And that is something that we have helped Jeb and the team at Morgan and Morgan do. So, Jeb, why don't you tell us a little bit about your role, at Morgan and Morgan, and a little bit about, what gear set has done for you so far and maybe a little bit of an overview of what we're gonna see today. Sure. That sounds good.

So, introductions. My name's Jeff Garrett. I'm the platform solutions manager here at Morgan and Morgan. Basically what that means is I oversee all of our ad in our DevOps process that we use in order to get changes in the Salesforce.

So since I've been on the team, we've had some pretty tremendous growth over the last three years.

The team has grown from just me and one other person too. Now we have, I believe fourteen admins in the system, as well as six developers and a whole QA team. So it's, pretty pretty, aggressive as far as, you know, the amount of changes that we're moving through before we got started with gear set, we were we had actually used a different product.

But only for a short amount of time. So we really were using change sets. It's a very basic process. And, you know, one of the things that I really liked about working with the people or with the team over here at, gear set is how easy it was to transition from, hey, you know, you don't really have to have a very advanced process at all or a whole lot of understanding of git.

There are things that Your set can provide you just out of the box without having to dive into that that we're gonna see today as far as, like, you know, hey, if you're not ready for that, Here's the kind of, functionality that that you can expect that will really help you in your process. And then I'll kind of show you as we case through it, how we get further and further, and then eventually we'll lead into, the pipelines tool and show you how some of that functionality works in pipeline. So I I really have a a three phased approach here. We'll show you just kind of like what a basic org to org deployment looks like.

Some of the features that are available there. Will then show some of the, flexibility with the kind of branching strategies that you can have doing kind of like an org first model for those who aren't ready to commit directly and to get, yet, and then we'll go right into pipelines where we'll see, you know, a a a get first model moving forward. So that's that's really the plan here.

So with that, Jack, or what? I I am absolutely ready to go. So we got, got amazing things for us to to look at here and Jeff, I'm really excited to to have a real life gear set customer, show some the folks on the webinar today, what gear set is capable of, rather than rather than just having someone from gear set show you, we thought let's let's bring a real life customer to y'all and show you from their perspective how how gear set can can help transform some of that. All y'all hope you're excited to this talk is somewhat off the back of an amazing presentation that Jeb and one of my colleagues did at Dreamforce earlier this year.

So, hold on to to y'all's hat and Jeff, but I further do take it away. Alright. Awesome. Well, let me go ahead and get my screen share going here.

Make sure I got the correct screen.

It should be right there. Perfect. So you guys should see the compare and deploy And then on the right, I have, Jira open over here as well. Everyone's seeing that?

Yeah. We're seeing it, Jeff. Thank you. Okay. Perfect. So before we get started, I'll just kind of, grab a grab a screen that we have from the presentation just to kinda, you know, just to kinda show how we're going to kinda progress here.

So I no matter where you are in your dev ops journey, Gearset has something for you. So, one of the biggest or one of, you know, kind of the keys I think that Richard, Richard, one of the product managers over at Gearsat put together, but I think really displays a lot of what we're gonna go through here and and how you should think about your DevOps process is kind of on this slide. So, this is really just kind of laying out, you know, what is the maturity of your DevOps process. Right?

So you can see there's hopefully everyone can see this. It's not too small. But you can see we have a few different levels here. Right?

So kind of going from level one to five novice to expert. Right? Where level one's just being like, hey, you know, you're just using change sets. You don't really have a whole lot of, functionality going outside of, you know, just moving changes.

And that's kind of where we were in the beginning. We were, just using change sets. We were using, spreadsheets in order to keep track of those changes. And then as you keep going, you can start getting a little bit more by involve your devs may start some of the DX CLI tools get incorporated with change sets.

And then you can get to more of an intermediate where we're going to kind of see more of a DevOps tool with the change monitoring, some of the functionality there, then we start getting to level four, which is really where I think pipelines really starts taking over start getting kind of more of a Git first model CI based approach. And then level five, which is really where you have everything going. Right? You have a change monitor in CI.

You have you know, re automated regression testing, stuff like that. So when we first came in here, we were kind we when we first met with gearset, we were probably somewhere here in the middle between novice and beginner. We're using change sets. We had some we had, you know, some of our devs using some CLI to push some stuff.

But for the most part, we weren't really involved there. And I'll show you towards the end where we'll get around this advanced to expert level. Right? And then from there, we'll kind of touch base if we have time at the end on any of, kind of Gotcha's or any sort of special circumstances that come up and what you guys can kind of expect from that.

So let me go ahead and put this away for now.

And get my handy dandy notebook here. Alright. So the first thing we're gonna do is go ahead and run through a very pull org to org change. So there's a few things that I'm gonna point out here.

Number one, just some of the functionality with the comparison tool and then how it handles some of the metadata items including permissions. So, fortunately over here in Git, I have this nice, or or ticket set up. So we'll go ahead and, we'll go ahead and move this to in progress because I'm gonna go ahead and start working on it. And before you get anything set up here, for those of you who are familiar with gear set, you'll wanna make sure that you set up your Sandboxes and your source control. So, I've already have these set up, but I'll just kinda, show you guys here really briefly.

And if it's too small, please let me know so I can make it bigger, but I'll try to make it a little bit bigger. I know my screen's a little small here.

So here's, you know, the, organizations you have set up. So basically, these are your credentials that you have for any given sandbox that you wanna connect. They're really easy to set up. You just click add new organization, to find whether or not it's sandbox production or developer.

You can put in your username here or if you're using domains. You can put in your enhanced domain here. Everyone should be really using enhanced domains at this point, but, that's a whole another story. After that, you authenticate, it'll take you into, Salesforce authentication kinda step by step very straightforward.

Like I said, I already have these set up, so we don't need to do that. The other thing that we'll need to set up is any sort of connection do you have to any sort of source control or third party system. So Recently gear set did start incorporating these team shared resources. So this this includes for sandboxes and for any of the resources here.

For this demo, I didn't set any of those up. It's newer functionality, but that is something that we're going to be looking at moving to shortly. So as you can see here, I have Bitbucket connected and also Jira.

These are very straightforward setups, I believe, for the Jira setup do have to, configure some back end, pieces for the web service to make a call in. But it's very straightforward and honestly takes about ten minutes to set up. Very easy. So after you get that all set up, you can go straight to compare and deploy, and let's go ahead and start doing a deployment. So I'll go ahead and select from, we're going to move from our dev sandbox.

And for this situation, we'll go ahead and move into UAT.

So after we, you select the sandboxes you wanna move to, you'll go ahead and select your filter here. So, it comes with a bunch of standard filters. We're gonna go ahead and stick with the default comparison filter for now. But if you are like us and work in a very large org, sometimes that doesn't work so well, and you may need to come in here and manage your custom filters. So this is where it's actually filtering the metadata that you want to compare, before going between the systems.

So in this or so in here, you can see it has the default comparison here, but you could clear them out, narrow it down. And this like I said, this works very well if you have a lot of if you have a lot of changes in your org as this, may take a while otherwise. But for here, everything seems to be working pretty quickly. We'll go ahead and do the standard comparison.

So go ahead and compare now.

And at this point, what gear set is doing is actually grabbing your metadata, from the different or from those orgs storing it in their back end and then performing a diff to see what the, the changes are there. Anything that doesn't have a change will show as having no change. Anything that does have a change does this having to change, and then you can also see deleted, or remove or or, modified items as well.

Looking at the notes here. While this is going, We're using git, Slack Jira. We need to show Jira ticket number when we move from one org to another in Slack. I said webhook and everything.

It's not coming source command ID, not number of the Jira ticket. I took the gear set, which said you guys which you guys said, it will come online now. Is that on if so, please set up a guide. So I don't have any integrations with Slack here.

I really focus more on the integration with Jira. But you should be able to do that with a webhook. I know there is some documentation related to it. That I have that I actually looked over yesterday.

And I'll try to see if we have some time at the end, and we can we can tie tech into that. But that's a great question.

So, as you can see here, we have the comparison kinda set or we have the comparison set up. So what are we looking for? Where we're looking for an called chores and completed date and status.

So if I go here, you can see you have all items, new items changed items. We'll just stick with all items for now. I'll type in chores.

And as you can see, my chore object comes right up. I'll go ahead and select it. And then the two other items here I need are the completed date and the status. So I can see the two items here.

One of the other, really good functionalities here is able to go in here, look at the components. And as you can see, it already pre selects those components related to it. So you can kinda see, hey, here's the top level object. Here are the components related to it.

The other piece here is we have a permission that we set up. So for those of you who are familiar, Salesforce is making a transition over to using permission sets from, profiles. I went ahead and did that as well. And as you can see, we have our permission set here that needs to move, and we're gonna go ahead and grab the whole permission set.

But if we didn't want to grab if we did if we already let's say had the permission set in and just wanted to grab the proofs the particular permissions, we could actually grab them here as well. So you can see the two items here for the permissions for that permission set, for the completed date and the status. So we could also grab those here as well.

But we should have everything we need off here. Looks like we got the field permissions. Perfect. Everything looks good. So go ahead and move these up.

And you can see we have some automatic fixes. So let's go ahead and look here.

It says new items were found in your deployment with entries for existing preliminary positions that are not included in deployment, deploy these new entries into existing profiles and versions to keep them up to date. So as you can see, there are a number of profiles that have permissions related to this particular permission set and you can see it's on the two different fields.

For this since we're just moving the permission set, we won't include those, but this is another thing that or this is, again, another piece of functionality that you get out of gear set without even having to incorporate yet, is being able to do these evaluations to make sure that you're not missing any items that maybe you should be included.

So we're going to go ahead and, move on without it. It gives us this morning.

Alright.

And we'll put a friendly name here. I like to keep my names, in line with our tickets. So g s t g s test dash two and object and permissions.

Or general.

From here, you can see we have our issue tracking, so our Jira integration.

So the Jira integration, it it's it's pretty straightforward, very easy to use. As you can see, you can select your project if you have multiple projects for, our for our integration in the, Jira, we just have one for right now. And then you can go down to your or your ticket that you see, or you can start typing in the name of the ticket. So, test two.

Oh, and there we go. And then another nice thing you can do here is you can actually change status of your ticket directly in here. So for instance, if you're committing into UAT, let's say you could go ahead and update it to UAT. So we'll go ahead and do that.

And we'll go ahead and deploy now.

So the deployment will go ahead and kick off.

Alright. And while we wait on this, it's moving pretty quick, but let's see. Wow. That was very quick. I actually didn't even have time to look at some of these questions, but let's look.

Are there any permissions that you cannot deploy through gear set or have it to complete manually post deployment instead?

Absolutely. There are some items that the metadata, I I don't know if they're, I'm trying to think permission specific I do know that there is a situation where if you're doing field dependencies, let's say if you you have two dependent fields you have to actually set up that dependency first in the org before you're able to deploy into it. That would be a situation that would come up.

There may be some others, but that's the one that comes to mind, just reading that.

We'll see if we can dive into that a little bit later well. So as you can see, we have the items deployed here, and, looks like it was successful, went directly in.

And if we go over into our UAT sandbox and go over to object manager, you can see that our item deployed right over here. So we have this, boom, we have the appointment, we have the fields we created, and if we go over into our permissions.

Oh, just because I am in incognito mode, but we can hop over here real quick. And you can see we have chore permissions right here. And the permissions have moved over on there as well. I can dive into that, but, might be pretty clear. So anyways, so this is the, this, like I said, this is very, very, very basic integration. This is without doing any sort of get, get connections or anything like that.

So what are some of the what are the big kind of takeaways from here? So without doing any git, any any sort of git connection, you have a comparison filter. You, you have, comparison filters.

You are able to, deploy directly org to org. You're able to use the the, comparison tool, which enables you to select the different items. You can actually see the diff there on the screen, as you can see on the bottom before. And you're able to connect this to Jira, or whatever your, system is for tracking your your tickets and items as well. And do updates because if you can see over here, if I refresh this, I should see that our ticket has now moved over in the UAT. And then if we look at the Jira ticket here as well, we can see that, I have turned on being able to or I've turned on it was one of the check boxes there. I pointed it out to you guys.

But it actually writes in the items that were deployed as well. So we can see right here real quick, hey, there was a deployment started, deployment succeeded. If we wanna dive in there, we can. And we can see that, the chore object and the, chore permission set were moved up. So a lot of good, visuals here inside Jira too for those of you who need who use this to track the items that you're deploying.

So let's see.

Moving along. I didn't wanna keep this going.

Do we include? It seems it never makes it when I'm deploying fields.

Alright. I will jump back to the questions a little bit. I wanna make sure we get through this next piece, for you guys.

But our next part that we're gonna dive into. So this is what I like to call the org first model. So when the org first model what we're basically looking at is trying to, get is is trying to getting involved with git without fully you know, diving in. Right?

So I'll go ahead and show you kind of what that branching strategy is. So I'll pull again our, little presentation down here. And here's what our initial branching strategy looks like. This is actually what we did when we first went to gear set.

We wanted to stay involved with git we wanted to, utilize branching because, like, we could see the value there. However, we weren't fully ready to, accept or to start running thing out of git and using git as the source of truth. The reason for that is we had been on another system. We had some bad experiences and we just wanted to make sure that we were able to, that we were still keeping the team involved, but at the same time, we couldn't afford a process that was gonna give more problems than solution.

So this is what we came up with. And basically on this sort of, integration, you're going to be pulling your feature branches coming from Maine doing your commits from your dev sandbox. And then for everywhere, we kinda move up to, we're using that feature branch to move those changes. So the idea is you have a feature branch that has incorporated all the changes that you wanna push and we're you and we're using that to move to the different sandboxes.

And then from there, we're committing down from the different branches or, sorry, from the different orgs into the branch that's associated So here you can see we have a UAT and release branch, and the main is being synced up with prod. So again, this is org first as an org is getting the items, and then we have the sink coming down. Some of the advantages to this is on top of, just having to roll back which is an org to org that's really the backup that you have is the rollback functionality because gear set's actually taking a snapshot of your data when you do that deploy it when you deploy it and it's storing it in the background so you can access it later.

This way, you have you can still do the rollback, but you also have your feature branch, and then you also have the backups that are moving to these particular branches. And the last thing I wanted to point out was at the time, like I said, we were you know, still kind of apprehensive from git because we had some problems so that we are on our previous system. So we decided to do a straight org to order deployment here at the end. So what does something like this look like?

Well, let's take a dive. So, getting back into my demo here.

I'll go ahead. The first thing you need to do to set up an org to org, kind of comparison is you're gonna wanna jump over here to the CI jobs.

And then we're going to wanna have we want to go and set up a CI job, for moving those down. So as you can see, I have production and UAT set up here on v one. The PLs, don't worry about those right now. Those are part of the pipeline. But you can see we have, v one Prod and V1, UAT.

So we'll wanna go ahead and set up CI jobs. So I'm going to go ahead and set one up.

We'll call it b one staging.

The source will be Salesforce, we're gonna go ahead and go to our staging environment. And again, like I said, this is really serving as more of a back Right? This would be a nightly job we run every night. So we're gonna go to our repo Salesforce production, and we're gonna go ahead and create a new branch from Maine.

And call it stage two.

We'll create that branch Alright. Now that we've created that branch. We'll go ahead and click next. That's also a very nice functionality if you guys have not seen it before. Being able to create branches directly inside of gear set, saves you a lot of time.

So for this particular branch, It'll be deployment. We're gonna do a full sync between the systems because you only have Delta CI if you're going, branch to org, which we'll dive into when we get to, pipelines, and we're gonna go ahead and set this to run every twenty four hours.

And then we're gonna choose what we wanna include. So new items, changed items, deleted items, I recommend including that and then also permissions job. So if, there is some warning here because potentially you could, lock yourself out if you have particular profile, that has that you're assigned to that has these changes.

But if you want permissions to deploy, you need to check this. So make sure you get that checked. We'll go ahead and hit next.

So here we have the Apex test or any sort of Apex test we want to run. We're just gonna use default test for now.

And then we have our, filters that we run. So, like I had mentioned before, if we're going inside the comparison tool you're able to select, the different filters that you want. Here, you can actually customize it. So if you wanted to select different items, or much in any way you wanted to, you can. But for now, I already have a, filter that I had saved before that has my standard CI jobs, so I'm gonna go ahead and select that. A few things to note when you're setting up CI jobs, and one of the things that I think is very power full about this tool is the ability to use, regets to specify items you want. So if you're like us, you probably have a lot of manage packages in your system.

So, we definitely want to include or so we include all of them. The reason for that is there's a lot of objects in those managed packages that we have to work add up. If you wanna be able to deploy any any of that information, you need to make sure to include the managed packages. Otherwise, if you don't have any managed packages, you can turn this off.

One thing to note, however, is that if you are using managed packages and they are using lightning web components, lightning web components for whatever reason when the, when the the, metadata API pulls them down, don't include the prefix on them. So if you have two lightning web components and two per packages that both have the same name, you will get a pro you will potentially have a problem, that will prevent the sync from happening. But fortunately, gear set does give us, tools that enable us to get around that. So if I go to lightning web components here, Let's see if find it.

Lending web components.

You can actually, unselect the including all and you can use a reg regular expression to include. So, one of the things that I've been doing is, I believe it was dot star.

I actually have to check my other deployment real quick to get these.

Let me get this. Give me one second.

So I'll include dot star.

And then I want to remove anything that has to underscores in it because two underscores would signify that you were, that you had an item in particular that was, part of a managed package you can exclude these as well. So what this will do is this will include basically any item that's named in the package, and then it will remove anything that has an underscore underscore. So the idea is the excludes override the includes. This, like I said, this is very important if you guys have a lot of managed packages or if you have a lot of data in your system. Otherwise, you may not run this. So give me just one second. I wanna make sure that I have this all set up right.

I'll actually let's see. For the sake of time, I'm actually going to omit this for now. But just note that there is this functionality here. So we'll go ahead and click next.

Once we do that, we have the static code analysis rules.

I just go ahead and use the standard rule sets, talk with your developers. If there's anything they wanna do here as far as any of these, they wanna turn off or turn on. And then you can choose whether or not you want this deployment to fail if there's any sort of problems there. For right now, we're gonna go ahead and leave that off.

This is where we're getting to the webhooks. I think there was a question earlier about any sort of webhooks diving into slack or any other integrations, you can set those up here. And then there's also a good bit of documentation. I definitely recommend reading through these links.

If you guys have not read through these, gear set is very good about updating them. In fact, it's very hard for me to find any links that say they have not been updated within the last two two weeks. So they definitely stay up on this as well, but we'll, and again, you can choose select or failure. Go ahead and click next.

And then we get to this final place final place which is the analysis template. So this is something where you can set up your own custom templates. If you go into my account over here, and you can dive in to, some of your problem analyzer templates, and you can choose anything you want to turn off or on. I would highly suggest on CI jobs that you don't run these.

The reason for that is occasionally they will have an item in there that will cause you, more of a headache than it's worth.

One of those, is where it actually removes, if I remember correctly, removes changes. There's one of them in here that will actually, potentially remove pick list values from a record type. We've had that cause problems before. I think it's something that's good to turn on if just doing an individual comparison, but when you're doing CI jobs, sometimes the problem analyzer can cause issues. Again, I highly recommend you go through, understand what each one of these does, but for right now, we're actually not going to apply any of them. Click next and then you get this last piece here where you're able to put in any sort of notifications that you wanna run. So I'll go ahead and put my email in here as well.

And then if you wanted to put your phone number for any sort of text notifications, you can go ahead and put that in here as well. And then here's where you can have, your Slack integration Microsoft teams and whatnot. And again, if you click this question mark, you get taken right to this channel, which was up see updated over a week ago.

But it dives right into how you can set up a, service or an app inside of Slack and have that integrate over.

So we'll go ahead and hit save.

And there we go. We now have our CI job up and running, so you can now CPI staging, and it is now in status of pending because it is now running.

So while we're waiting on that, I'll go ahead show you how we do a deployment, and kind of this Git first model.

So we'll go ahead and grab our next ticket here, move it over a new in progress, And here we go. So we have an org first, lightning record deployment that we wanna do. So we have a, lightning record page we want to deploy. So what I'll do is I'll go ahead here, select my dev environment, go into source control, select my repo, click on main, and then we wanna create a new brand remains. So again, I like to use the naming convention of our ticket here. So we'll go ahead and name this feature forward slash, g s test dash three.

Create that branch.

And then again, if you have, an org that has a lot of metadata, will definitely wanna filter this down, but we'll go ahead and skip that and use the regular, comparison filter here and click connect.

While we're doing that, let's see.

How did you decide what metadata items to store in each branch since gear set recommends not storing them all? Great question, and it's going to vary about your use case. So one of the things to understand about DevOps, in in Salesforce versus DevOps in almost any other system or especially where, you know, you have the servers in house. You have developers in house. You're developing directly against it is the minute you is there's a there will be drift in these branches. And what I mean by that is where the org does not exactly represent what the repo does.

The reason why that happens is because let's say there's certain items that you wanna sync to your repo, or that, you know, you wanna deploy, like, for instance, objects, Apex classes, or, you know, come to mind. Pretty much in almost every situation you're gonna pull those down. But there's other situations where you may wanna pull something down to your repo, but it may but it's something that you don't wanna lock down for your end user So for instance, reports dashboards, those are pushed through the metadata, API. And if you, let's say, we're needed to put a dashboard on a layout, that would be an item that, yeah, you would wanna pull down and get.

But at the same time, You'd you probably don't wanna lock down reports in your pro in your production instance, and you probably wanna let some either users or super user mess with reports and dashboards in there as well. So there's some strategies that you can do there. I highly recommend using the monitoring functionality, which, if we kinda jump back here real quick and go into, sorry wrong one. Salesforce orgs.

When you're setting up a new org, you can actually check this monitor the org for metadata changes. You can use that to monitor it or you can use a combination of a CI job that's being used as a backup as long as well with the, job that you setting up for pipelines.

There's a lot of different strategies. I would definitely like to dive into it, but that that is a very good question because it's it's going to vary amongst every use case based upon what you will want your users to, change in the system.

But no, no, absolutely great questions.

So from there, we went ahead. We have our, changes here. So let's see. We'll go ahead and find this record page remains.

So this was on the account object, account client support. So I'll go ahead and search for that. And here we go. We have the Lightning page right here.

I'll go ahead and select it. And as you can see here, we have the metadata, on the lightning page. Again, since this is a brand new item, you don't see any changes here on the right. If you did have a changed item, which we'll kinda dive over here real quick just so you guys can see one.

Let's see if we got a good one. Oh, these are duper rules. Let's see what it looks like. You'll get a comparison like this.

So one of the, again, one of the big functionalities being able see the red that's being removed, being able to see the green that's added in. But the other thing too is the metadata API sometimes is very weird. In that it doesn't actually, it'll it'll tell you that there's changes where there isn't actually. And that's why gear set made this simplified differences.

So if you notice in here, the metadata API returned, hey, on line seventeen through thirty two, here are these mapping for, mailing city, account ID, email, and first name. But down here, you can see it's the exact same mapping. So even though in git, this looks like a difference because it moved places, you can see if you do simplify differences, gear set smart enough to know, hey, there's or actually a difference. There isn't actually a difference here, and you can kinda see it straight straightforward, so you don't have to, using the simplified differences.

So you don't have to see the so you don't have to deploy something that isn't needed. I would say the thing that's mostly probably useful with that is with layouts. If you guys are familiar with layouts, there's certain items on there where it'll think there's a change when there isn't actually, and gear set does a great job turn those out. So go ahead and hit next.

VR changes.

Unsupported metadata. So, this is likely because in our repo, I am, a version or two behind. I can show you guys kind of where that's configured. But basically, when you run the, metadata API, when you run the metadata API and gearset, it's looking at the version in both your source and destination and pulling back what you have there. This shouldn't be a problem because I'm going directly into the info. So I'll go or into my branch. So I'll go ahead and uncheck that and click continue.

And added a lightning or third page. I would highly suggest you can actually make commit messages mandatory. I highly suggest, you know, your teams get used to adding that in. I think any the more documentation you can have, but better.

So we'll go ahead and go to our our org and then we'll slide down to GS three. And we can see it's in progress. And then this is where I was showing you before I should have pointed this out. You can select which items you want to sync over. So we'll go ahead and commit to those.

And as this runs, I'll try to see if I can answer another question. Sometimes after deployments are successful to failure, it doesn't show up in the CI job history. View history, it's also difficult to identify when the deployment was done by which users.

As there is no filter to apply and no column apart from the time stamp. Interesting.

I'll try diving again if I have some time, I we're kind of running up here. One more section to show you. I'll try to dive into that. But here you can see we have our commit.

We go straight or so we have it into the branch now. Right? But according to our branch, strategy we needed to get into UAT. So the easiest way to do this that I found is you go straight into deployment history.

You find the change that you made. So here's GST or the search works very well for this. If you know what the name of your branch is, we can do it right there. Boom.

I have my branch right here. And you wanna go ahead and click clone package, and then you wanna select the source and destination. So the source is the branch that we just went to, which is GS three, and then the destination would be our next org, which would be UAT. Click run comparison.

So the thing that's really cool about this is what it'll do is it'll use the same comparison filters that you've used on the previous deployment and any item that was selected will be preselected.

Again, this is kind of outside of the norm on a git process. It's a little bit more manual than what we'll see in pipelines.

But it's a step in that direction. So we'll let this run. And as you can see, it pre has, this item preselected.

It's the same filter. And we can go ahead and run through. It's giving us a warning because it's not done retrieving everything from the target, but we have what we need. So we'll go ahead and move forward.

We'll skip the problem analyzer for now.

And I like to go ahead and append on here which environment I'm moving to. So this time we're moving to UIT, I'll append there. And here's our Jira ticket, and since we're moving to UAT, I'll go ahead and up this to UAT, and you can choose validated deploy, but we'll deploy now.

So now this is going into UAT. So eventually we get to that last step, like I said, that we wanna go ahead and jump directly from releasing the prod. Again, in this gift first model, what I would say is the best way to do that is to actually use the deployment history. So if you're using if you're using Jira, you can set up some releases. So I went ahead and set up this release one dot o, and we'll go ahead and go back into this item. It should be updated now.

Perfect. It says UAT. We get the items here as well. So now you can actually see here. Hey, this is when we committed into the branch. This is when we committed to, the UAT environment.

And this is ready let's say this is ready to go. So we'll go ahead and say ready for release and go ahead and move it into that fixed version. What's fairly nice is your release managers can Hop in Najira. Go into that release, say, Hey, we have this ticket that needs to move up. Go to deployment history.

Go ahead and type it in, the S test, and we can see, and we can say, hey, we want the one that went to UAT. It's a little cramped here, but you can see this guy right here. That's the one we want. We can go ahead and select that. If you have another one, let's say there were two items in here, you can go ahead and select that next branch, click combine packages, and then this is where we do that last jump. Like I said, between release and prod, we can go ahead and select the source as being, well, in this situation, it would be UAT, and then the next environment broad. Run comparison.

And the nice thing about this is what it'll do is it'll actually combine the filters from both of those items and the items that were preselected so that this way, the items go or so that this way, you don't have to sit here and pick and choose each item coming out of there. We'll go ahead and let this run real quick. It's been going pretty fast today. Been pretty impressed.

That's the one surefire thing you can say during a live demo, Jeff, that's gonna make it run slow. Yeah. No. I shouldn't have said that. I really shouldn't have that one. So that was a bad piece there.

But while we're letting while we're letting this go, And, and really the main key here is I just want you guys to see how it kind of adds the comparison in there. We'll go ahead and dive into the last part.

Which will be, pipeline. So before we leave though, a few of the highlights here, setting up CI jobs, understanding a branch and strategies very important.

This one, in particular, using branches to move your changes in between. So you have that as a backup, and being able to clone packages is a very, very full functionality.

Now as far as your backups that you would have, so like I said, what you're doing just straight org to org, you have the rollbacks as kind of your your fail over. Here we have three. You have the branches. You have CI jobs, and then you have rollbacks.

So you have a few different places that you can go if you need changes going in. So again, here's the comparison. We're not going to deploy this, but as you can see, it ran our comparison on the filters that we had, and it's preselected those three So you could imagine if you had fifteen tickets that had, you know, thirty items selected, this will go ahead and pre combine them, use those few filters pre select them for you. Another reason why you really wanna narrow down those metadata filters.

So the last piece that we have here, which is our pipelines get first model, and I'll try to run through this really quick. But the, branching strategy that we have there is a little bit different. So, here we have a, a dev sandbox.

It'll sync that branch into UAT and then it'll, do a merge going into the release branch, which is what we set up in pipelines. I'll show you, us doing that. That's how you combine your items, that, or that validates against prod. And then when we merge in, that CI job is what will also push that in the UAT. It's very important when we do this that we set everything up using using Delta CI. So the difference between a full sync full sync is whatever's in the repo is going to ride into or the org.

It You know, if no one's making any changes in that metadata, that's great, but I highly suggest using Delta CI, it makes things a little bit friendlier. So we'll go ahead and go over in the pipeline. So here's a pipeline that I have set up. You'll notice a few different items here. We have prod, U AT, and dev, but let's go ahead and add an environment. So we'll add a static environment, which is where, you know, or which is basically where we'll have a job running. We'll create a new CI job.

We will call the CIJOBPL hotfix.

Alright.

We'll select our source branch, which is going to be the repo. You can see, it kind of has this all blocked off for you. And we will select the hotfix branch. But since I already did this once before, I'm gonna go ahead and create a new branch called Hotfix two just to make sure that everything is everything's going well. So, we'll go ahead and create this branch hotfix too. Wait for it to create.

Perfect. There, and then we're going to sync this over to our staging environment. Usually, we'd have a different environment, but we're using staging for the hotfix in this situation. So we'll go click next.

And again, you can see the screen looked very familiar. And this time, we're going to be using the Delta CI. So if you want more information on it, there's some, there's some documentation here. But basically only the changes that sees going into the repo are the ones that's going to try to deploy.

So, again, we'll use, deleted, and, we'll include those items for permissions.

As far as test runs, so there's a few different settings here. I'll really quickly go through this You can either do all tests, default tests, or you can specify the test to run. This is where it gets kind of interesting because you can either specify particular test classes, test suites, tests that are referencing in Apex changes, which I don't remember exactly how that one is calculated, but there are some caveats to it. I would definitely under recommend learning more about the ci jobs here. But the one that I prefer to use is this test matching naming conventions for Apex changes in the deployment. So what that basically means is if you have a class that's, let's say, called chores handler.

And the test class to it is chores handler test. That's a pretty normal naming convention. It will know to run as long as you move those together or they're in the or they're in the branches, it'll know to run chore, chores handler test whenever you're pushing chores handler. And it has a few different combinations with underscores so it can be underscore test or hyphen tests, some some pieces like that.

Again, I highly recommend you check here. But this is what I would recommend setting up for the purposes of this, well, actually I'll just keep that on for now. You can run lightning web component as well. Just fail.

I'm gonna leave that off for now.

Automated UI test will leave off. So again, we're going here. I have this job set up. I'll go ahead and select it. Click next. We're gonna use the standard, stat code analysis, and not gonna set up any webhooks. And then again, we're not going to apply any of the, analysis changes.

And then if you want, again, if you wanted any notifications, you can set that up. So we'll go ahead and save it and boom. It was that easy. We now have an org that is in the system, and you can see it's blue, which means the job's running. So we need to connect it into the pipeline.

The way we do that is we just click edit environments, and you got a nice little change here. System says this is hotfix. We'll connect it into prod, click save changes, and now you can see we have our prod instance with hotfix sitting up here. So we'll go ahead and push change up. One of the things I did wanna show you is, some of the validations, that can go in here or some of the, conflict resolutions.

So we'll go ahead and I don't know if I have time to fully dive through all of them, but let's go ahead and commit a change.

So I'll jump over into bitbucket and I'll go to my Apex conflict And I'll go and as you can see, we have a class called pipeline sample demo. So I'll go ahead, do my compare and commit. And this is one of the or against a branch for GS four. So as I can see GS test fours here, but I'll go ahead and create a new one.

So let's say GS test four for whatever reason we have problems with that So we'll go ahead and create a new one. I highly recommend that you use kind of the same naming convention. So we'll do four, and then we'll do one. So I know that this is the second one we did.

We'll create this branch.

We'll do a compare and commit. And then as you can see, it does our standard filters. One of the things that I would or that, I would like this is if you're in a larger org, sometimes these standard filters aren't gonna work so well for you guys, and you wanna slim them down. So I'll kinda show you how we'll do that as well, but let's go ahead and and commit this for now.

So it's gonna go ahead and do that comparison.

Sitting here, I'll try to read this Got some great questions. Clickup. I have used Clickup. I really like it. I am not sure if we have an integration there though. That is a great question though.

Not for clickup just yet. Again, for any feature requests or integration requests and things like that. You'll see in the q and a we've been point pointed a couple of people to use your voice already use your voice. It's tier six feedback form, for the product and dev teams, which is just right popping in there.

Excellent. Awesome. So go ahead and select this Apex class, and we'll go ahead and move it up very quickly.

No problems found. As you can see, you have some code quality improvements. You can check those out. We'll leave those alone for now.

And Apex bus, bimmo.

We'll go again. We'll go ahead and select it. We'll go ahead and select it to they're connected to this ticket, and we'll commit our change.

Cool. So once this is up, you can create the pull request directly from here, or you can go back into pipelines, I'll show you how you can commit it in pipelines.

You have your branch. So we'll go ahead here as four dot one. You can see that we have a commit on it. It's ready to go to UAT. That's it's connected. So we'll create the full request PR to UAT, create the full request.

Cool, and now it's done. You can go ahead and click cancel. And if we jump over here, You can see that that three became a four, and here's this item going in. So the first thing it does is it does a merge conflict check.

To see if there's any items that conflict with this going up. After that runs, it will attempt to do a validation. And that's where some of those jobs come in, like I was saying, especially with Apex. So as you can see, this item, did pass.

And so it looks like it or it's or it, sorry, it passed its merge conflict check. So it's doing running validation right now. If we wanna monitor it, we can.

Outside that, I will go ahead and click to promote changes.

So note that you can promote before the validation's done. So we'll go ahead and try to do that for now.

But while that is running, you can see and you can see the validation succeeded, so it's gonna attempt to push in right now. That's running, we actually do have an Apex, that has a a a conflict check here. So I'll go ahead and dive into it to show you kind of what that looks like.

So one of the, one of the nice functionalities and gear set, and it's the thing that we had a lot of problems with before we're merging. So, this is the semantic merging. This is specific to certain or certain metadata types. The Apex classes are one of those.

And as you can see here, you can see the changes in particular and choose which ones you want. So you can actually either choose one, the other, or you could combine them both. So as you can see here, the change was we, changed the name of a variable, from value one, or from value to value one. So, for what I want, I'm gonna go ahead and select the changes that were in my branch, like Mark does resolve, and click commit merge.

And this will now go ahead and commit that into the or we'll merge those items together. The way this works is whenever you create a pull request against an environment.

Gear set's really good about actually merging those items in four or is really good about creating a a promotion branch where it's kind of in between your feature branch and the org, and then that's where this merge actually occurs. So if we look back inside a bit bucket, and we look at our branches. Actually our branches are committs easier to see. Let's go branches. You'll notice that we have some items such as this one. Here's that GS four dot one and then see it says dash main. That's because if we're looking at four one, You can see our feature branch and you can see main, and that's because if we're looking in the pipeline, we can see that four dot one is waiting to go into prod.

So, this is where the this is where the last piece, we have five minutes trying to run through this really quick. We may we saw the merge conflict.

We'll go ahead and kinda go to the release. So one of the nice functionalities, and this is why we don't have a staging org anymore our ability to create releases before the staging org was kind of the collection of those. So what you can do is you can go down, select the items you wanna deploy, click create release. And so we'll name this release. I'd like to name it the same as what we have in here. So we'll go ahead and name it release one dot o. So release one dot o dot o merge into release.

And so what this will do is it's the same functionality kinda like when we were doing that clone, right? It's going to take both of those branches together or both of those branches merge them into a release branch, which is kind of your promotion branch that's going up. And then it'll perform validation checks, merge checks, all or merge checks validation, everything against that to move it up. So this sometimes can take a little bit.

So I won't, dwell on here too long. But one thing I do wanna, point out before we before you log off is, if you have a situation like we do, where again, I keep bringing this up. We have a lot of metadata in our system. Using predefined filters like you have here may not necessarily work.

Fortunately, you can still get items into the comparing or can still get items into your pipeline using some of the other functionalities. So for instance, compare and deploy, we'll go ahead and select dev.

We will go into our pipelines repo because that's the separate repo we're using here, and we'll create a new branch for main. And let's say for this next it g s five, we wanna move it up. So I'll go ahead and go into g s five, and we'll do feature forward slash g s test. Dash five, create branch.

Oh, sorry I have that. So I'll do g s five dot one. Create that branch.

And while this does, we'll go in here. And again, like I said, we're just wanting the Apex class here. Type an Apex Just select the item we want and hit okay. This will tremendously cut down on the time it takes to do the comparison.

Not sure how long it's gonna take with the metadata it's gotta compare, but we'll go ahead. Actually, you can see it was pretty lightning quick on the repo side.

Just grab the one item. Boom. There you go.

We'll go ahead and select this item. Click next.

Now nothing's changed in here. So we're not gonna see any change or it may not, catch any changes going into the next environment.

But we'll sit here and we'll do we'll name this. Outside.

Hypelines.

Again, we'll go ahead and click connect it in Jira, put our influence, go ahead and commit our changes.

And then after we commit our changes, we can do create pull request, select the environment we wanna go to. So in this case, it's UAT.

We wanna, you can skip validations if you want validations run automatically if you have a large team, they can sometimes hold up the org. We'll skip those. We'll include the items deployed, include the Jira links, and we'll go ahead and create click create pull request.

And there it is. It's gone ahead and created it. It knows this is part of pipeline. So if we go back and view in pipelines, You can see our items come in here. So so there's multiple different ways that you can do this. You can even commit directly from bitbucket.

Few of the other things here, you'll notice when it's in pipelines, you can see the Jira status here. You can link directly out. You can have multiple tickets on particular branch. There's a lot of stuff you can do.

Here's the release. As you can see, the release is validated. I'll go ahead and click this to kind of go in, but I know we're out of time. I really tried to fit in as much as I could.

Apologize for anything I didn't get here, but, Yeah. Let's, if we have any time for questions, we can go ahead and run through those. But, yeah, that's really just kind of, you know, how we set up. So Again, what, one of the things I did wanna point out just as far as, you know, your backups, the functionality here, this is definitely the way to go if you have larger teams trying to coordinate.

It's a lot easier on your release managers, being able to just select here, click the items they want, create the release. And then let's say if there are more items in here, you can keep adding them to the release and deploy it.

Once you get to a certain point, you're you you definitely wanna get here. But that's kind of a phased approach from org to org org first to pipelines and how I would move through this.

Jeff, thank you so much. What a whirlwind tour of the Morgan and Morgan gear set experience. Thank you so much for for sharing with everybody this. Q and a has been super super engaged. So thank you for those of you that have posted questions in there.

I really, really appreciate that.

The one question that I will answer live just now. So Brett has asked in pipelines downstream changes work similarly to upstream commits and pools. Yeah. So in pipelines, if you have commits, to upstream environments that need to go back down to other dev orgs.

You you will see that Jeb was clicking on the little pull request icons that pop up for example, that's, that one there, you'll see that that's a back promotion there as well. So, so yes, in answer to your question, you'll see that those stream changes need to go back downstream in gear sets, highlight that for you in the pipelines there as well. Tyler, I can see your question about, the pipeline is creating PRs for from one user. I think this is something that the team, team is looking at.

Again, I would suggest, suggest reaching out either either to support to to raise, to raise that as something that you would like like to look at.

Or if not suggesting a user voice ticket as well. But, we have, run over by a minute here. I know, folks are busy and have other places get to. If you need anything following this webinar recording will be sent out so you can come back and review all the amazing things that Jeff has showed us.

And now I'll be with you in the next, in the next couple of days by the end of the week for sure. Please feel free to share your colleagues, but, Jeff. I wanna say thank you month for for your time, super enthusiastic and, super in-depth, which I really appreciate. And I hope the users have too.

Yeah. No problem. It was it was a pleasure, you know, showing this to you guys. There's definitely a lot of gotchas that are in here.

I would love to be able to answer any questions we have. So Jack follow-up with you for any questions, the the, people that the attendees have, and we'll try to see if we can get some of those answered for you. But I hope you guys enjoyed it. Perfect.

Thank you, Jeff. Thank you, everybody for tuning in and we'll catch you another time on another webinar or out there on social or inside the app. Thank you folks. Have a great evening or rest of your day.