Description
The workshop recording from our Gearset 360 event, showcasing how to create and managed auomated CI/CD pipelines within Gearset.
Transcript
Awesome. So the easiest thing to do here is actually get the team lead for the day. So that's, that nominated yourself.
If you wanna go ahead and share your screen with the gear set app, we we can go ahead and start getting you set up, basically.
So everyone else, who's logged in to GearSet, this widget is just gonna do some kind of, again, like, team lead release manager actions here where we'll set up the pipeline. And then after that setup, I'll let you all know when you can dive in, and you'll be creating your DevOps in the pipeline, as well.
So I can guide you from here as well. So where you want to go through from here is, continuous integration. I've got a nice drawing I can do on the screen there. So gonna do that for you. Right.
So this should take you straight to pipelines.
What I've already done is I've already set up a couple of things. So, for anyone who might do this in future, I've set up a repository. We're using GitHub today. Obviously, we can integrate with all different Git providers, whatever your organization might use. You can get free accounts of these on the whole as well. So if you wanted to try out in a sort of a playground scenario, you can.
I've populated that repo with all of the metadata that I would like from production. So it is a almost exact copy of production for most of the metadata types that I want to to look at.
And then I've created a pipeline.
So at this point, we're gonna start to create what we call environments in pipelines to visualize the the stages of our pipeline. So we'll start with production.
We're gonna pull UAT into here, and do a couple of other things as well.
So, first things first is you just wanna hit that button called create environment, in the middle of the screen, and we're gonna start to create a new environment and job on the right.
So what we're gonna do is we're gonna create one for production here. So we'll call this prod or production, whatever you like, as the name.
We'll select a source branch. There's only one in the repo, and that's main. Production should always be aligned to your main branch as that's your your source of truth there. And then, yes, search for your target org. That'll be prod in this case. So what we're doing is setting up an automation job between, the branch, which is main, which sort of, replicates your production environment, and then the production org as well.
So we'll hit next on this one. This will take you through the wizard. At this point, there's not too much to change here, but I'll walk you through what's going on. So this is setting up the deployment behavior of this CI job. So we want this CI job to actually deploy changes from the branch to the org rather than just validate in this case.
We've got a synchronization type. I would always recommend to use delta c I in this case, which means anything that's been merged into the main branch, we only deploy what's been merged rather than comparing the entire branch.
Some people do different things, but Delta CI is predominantly what customers use.
We're gonna run the job, when the source branch is updated. So we'll be watching the main branch, to identify if any changes have happened to it, and then we'll kick off the job when that's happened.
Below, I think this is already preselected, but validating pull requests is really, really important.
This means if you're proposing any changes go into production, we're gonna pre validate those and make sure they actually work, run any tests, run any quality checks you need to, and any approvals before they actually go to production.
And then, yeah, we've got new and changed items for what types of changes we'll deploy. You can also deploy destructive changes, but we'll we'll leave that unchecked for now. So we'll stick with all the defaults here and just hit next.
So, Matt, I do have one question. So we use full sync between Git and Org today for our automated deployments today that we have. Mhmm. So and it was recommended to us, to use that.
Yeah.
So Do you do you folks use I get I'm guessing you're using just the CI jobs rather than pipelines here?
Right. That's right. Yep.
Got it. Okay.
It's up to you, really. You can do a full sync between the git git and org. It means that the branch is absolutely the source of truth, which some people much prefer.
It really depends on the size of your org. Some of our largest customers comparing the their entire repo and org every time it's over the APIs is just not performative for them. So it really depends on what you're going for here.
The benefits and pitfalls to both, but I'd say from a performance perspective, Delta CI would be better.
It depends how well aligned your branches and orgs are as well, but it sounds like your team have that fairly well handled.
So, again, it's a preference for your team and a decision you folks can make for sure.
Sure.
Cool. So this is just setting the test levels.
We're gonna keep this pretty much the same.
A lot of people would go to specify unit tests here, so specify test to run.
We won't do this for this time, but this is where we can dynamically select test classes based on dependencies of things you deployed, naming conventions of test classes, and and all sorts of other things. We're gonna keep it simple today, and just leave that there.
And this is where you'd select any LWC tests or other, UI tests you'd wanna run as well if you're integrating with other UI testing providers.
We'll keep it nice and vanilla, and we'll hit next on this one.
Cool. At this point, this is just your metadata filter. So this is defining what you want this job to deploy, so which metadata types you actually want it to take into account. In this case, we've got pipelines workshop filter. I would recommend aligning whatever filter you have for the metadata the metadata types, to be wherever's in your repo.
So wherever you've set up your repo what metadata you've set up to to be in your repo initially, save that as a filter, and that's almost your sort of go to from there.
You have one central place where you, can govern which metadata types go in and out.
So I would actually just go back to that selection of the workshop filter there, at the top. Yeah. And just select pipelines workshop, and we'll stick to that.
Cool.
Alright. If we hit next, this is static code analysis rule sets. We've got this set set up as a standard one.
Essentially, this is just gonna run code quality checks for any of your Apex, that your team might be doing here as well.
These can be run on your pull request validations too, so they become kind of a precheck where you might not want to actually push something forward if it's if it's got some sort of quality issue.
But we'll leave this as standard for now, and we'll hit next on this one.
And then these last bits are outgoing webhooks. So this is if you want gear sets, CI functionality to to talk to other systems, essentially. She might have some other automation going on, whether that is, UI testing, kicking off another automation server, something like that as well.
Again, we won't be doing any of that today, so we'll we'll hit next on that one.
And then problem analysis, we're gonna leave that to apply all fixes. There's built in problem analysis in Gear Set. Any of you who've used Gear Set a lot in the past, you'll know that we identify issues in deployments and fix them where we can. So we'll we'll do that here for now, but you you might want to switch this off sometimes. So we do allow users to do that.
So hit next.
And then just notifications.
A lot of folks use Slack. We use Slack internally or Microsoft Teams. So you might want a channel that, lets you know when this job fails or when there's been a deployment to production, or anything like that. So you can set notifications up on each environment to tell you what's going on with that.
And we'll leave it at that. We'll hit save on that one, and then that's gonna be everything we need to do here. And since I've explained all of the settings, we'll just sort of fast track through the other ones here. This webhook setting, is definitely important. We'll click add webhook there.
What that does is that essentially allows us to communicate with GitHub. So whenever there's updates to your branch or all requests open, it's gonna trigger off, the automations in gear set.
So we'll hit finished on that one, and then we should go back to the pipeline and start to see that environment set up. Cool. So we just need to do that, once more. Looks like two folks are setting up here. So we just want Bizwidget to set this up in this case. So, Bizwidget, I'm gonna say, if you can delete that other production one in a moment, we'll do that.
I think it's running at the moment. If you go to the cog in the top corner there There we go. We'll yeah. We'll just keep setting up some environments, and we'll we'll delete any other ones that that get set up there. But, yeah, just to confirm for the group, it's only Bizwidget who's showing his screen setting up these bits, and then everyone else is gonna dive in afterwards.
Where he's, playing the release manager for the day in this case. So we'll add another static environment. So that is, that's alright, Alex. I'm glad you're following along. So all good. You you obviously got all the instructions, so that's good to see.
Let's go create new environment and job.
Let's go for UAT on this one.
We're gonna do pretty much exactly the same, but what we need to do is select source branch, select main here, but you want to create a new branch from main.
That's it. Yeah. Select UAT as the, target, but we'll also before you go to next, if we hit create new branch from main here, just circled that, we'll create a new branch and call it UAT. So it's gonna be exact copy of main in this case. So it's got the same ancestry, but it's gonna represent our UAT org going forward.
Cool. And we'll just go next on pretty much everything here until we get to the end, I think.
This should all be yeah. That's all good.
Yeah. Perfect.
Yeah.
And then we can hit save on that one.
Awesome.
Cool.
So you've had the other one disabled. I think if you actually hover over that environment or, actually, if you click edit environments in the top corner, Bear with me a second. I can do it. Yep. Then you can, delete that environment there. Cool. And then save changes on that one.
So from here, the the next thing we're gonna do, just double checking, if there's any other environments we want to set up here. I think we've done UAT so far. So at this point, we've got some new functionality, that we're gonna set up here, and this is called a project, essentially.
So, sometimes, actually, in most Salesforce teams, you're working on business as usual sprint work that you'll release every one or two weeks.
But you might work on some long term projects that's in parallel to your normal releases. So we built some functionality where within the pipeline, you can have a long term project that sits in parallel, and you're able to interact with us in a little bit of a different way. So we're gonna set this up today, and I'll pick some users to work in the project and some to work in the pipeline. So if we go to add in the top right corner, we'll hit add project here.
So, we'll call this project whatever you like. This could be my long term project, my experience cloud project, whatever you whatever you like.
Cool. And we'll select, main as the base branch, but, actually, we wanna create a new branch from main in this case. So oftentimes, when people are working on projects, they will have their own project branch or what they call a developed branch that they'll be able to create feature branches from and build on top of previous work over over several months that might be released in a larger release. So we're gonna create that in this case. We'll call this project branch.
Cool. Create branch there. Perfect.
So within the project, your feature branch is gonna be created from this project branch, and in the main pipeline, they'll be created from main.
So there's a real difference between the project and your business as usual work in this case. So we'll hit add project there.
And, essentially, it creates a folder, which is almost like a a mini pipeline within within the pipeline as well. So to to set this up, we can just hit edit environments in the top right hand side there, And then we'll want to hook these up. So what we'll do is if you draw from the front of UAT to the back of production there, that'll create a connection between the two.
It might be the other way around, actually. So the the front of UAT yep. That's it. And then I think you can delete the other connection.
You can drag these and move these around, by the way. So if you I think we've drawn a bit you know, we might have drawn too much there. If you click the x in the middle, you can actually click on the main yeah. That's perfect.
And you can actually just grab the environment, like, click on it and drag it if you like to to move them around. But when you hit save, they'll snap together. And then we're actually gonna hook the project up to production in this case, just as a simple example in this case. So if you hit save changes there, that should snap everything together.
So we've got a fairly basic, pipeline here. We're just gonna do one last thing, for the release manager setup. So if we go into long term project, and just click there with my terrible art, We're gonna just create an environment in this project. There's a project integration.
You're definitely correct, Peggy. It would go into UAT first in most scenarios.
Today, just for the speed, I'm gonna have things promote from the project into production. In a real world scenario, you'd expect the project release to go into UAT.
If you've got an SIT or QA, probably even to that one. So, like, whatever is your first testing environment is typically what we'd usually see. See, you're absolutely correct.
Cool. Okay. So we're just gonna do one last thing in here. So create a new environment in job. Same thing as always. We'll call the job name integration.
We'll select the source branch. That's project branch in this case.
And the target, there should be one called project integration. So if you search project there, it should come straight up.
There you go. Perfect. And then we'll just hit next until we get to the end there, and we'll keep all the same setup as before.
Awesome.
Cool. And we're gonna do a little connection here. So if you click edit environments, we're gonna draw a connection from the front of integration to the little dot where it goes into prod there.
All just seeing a question from Sy. All the target orgs are preconfigured.
Yeah. We've created all the target orgs. In Gear Set, what you would do is connect to your orgs, like, when you're setting up in your own environments.
And then, yeah, you would create the branches and and choose which org when you're setting them up. So yeah. Exactly.
Cool. And hit save changes on that. Right. Now we're ready for everyone else to to pile back in. So to get back to the main pipeline, hit production there.
If you click on prod cool. So now everyone else can join in, and we're gonna we're gonna still visualize this on Bizwidget's screen because I think it's useful. But, for everyone else, you can go and add your own developer sandbox to this now. So if everyone I'm gonna highlight on the screen here, clicks add, including Bizmojit.
If you remember what user number you are on the team, then you can you can add your sandbox from that list. So if everyone goes to add in the corner there, there should be and including new business here. Yep. And add developer sandbox in this case. So developer sandboxes work a little bit differently in pipelines because they're not sort of tied to long lived branches or anything like that.
So we'll call this, my developer sandbox or dev one. It's up to you.
Then we can choose from the list of connected orgs. For you, that's dev sandbox one.
You don't need to assign this to a team member, but sometimes team leads want to, create these different environments then assign them to team members. They only see the sandbox that they would want them to see. But in this case, everyone sees everything. And we'll hit save on this one.
Cool.
And if everyone else has been following on, we should start to see a few more pop up on the screen. There we go. Max is in.
Alex is in. Great.
And we'll see if anyone else is in a moment as well.
Cool. So what you can do, Bishwager, is, you can edit the environments here and then hook them up to UAT. So then we're gonna have a full pipeline. So draw from the front of each of these into the back of UAT, and then we can hit save.
In fact there we go. Yeah. If you hit save on that one, it was all snapped together, and then it'll make more sense in a second.
Okay. We've got some funky lines there. Something's happened. So if you hit edit environment again, there's gonna be one that we need to delete there. So I'm looking.
I think that's fine. Yeah. Something's overlapping there. You've kicked that one.
Yeah. That looks about right. What I what I was actually gonna propose is one person maybe works out the project, and we can see how that comes comes in.
So it depends if you folks wanna see that functionality. But, if someone wants to create a dev sandbox in the long term project, so by clicking into it, I mean, you can visualize that on your screen, Bizwidget.
Or maybe we can get you to do this, actually.
We're gonna get you to create your dev sandbox in the project. So you're a developer just working on this project stream instead. So if you click ads in the corner and add your developer sandbox here, then we'll we'll go through this flow on your screen, and everyone else can go through the main one.
Cool. So we'll just add the same dev sandbox here, just for time's sake there.
Perfect.
Yeah. And we can just choose dev one again in this case. That's fine. And then, yeah, if we hit save on this one.
This one? Oh, it's fine.
Yeah. That's fine. Yeah. Yeah.
There we go.
Cool.
So, yeah, what we'll do is just hook this up to the integration in project branch, and we'll show you how we can release a sort of longer lived project alongside some of the business as usual work here as well. So hit edit environments, then just hook those up.
There you go. And hit save changes. Perfect.
So now we need to actually make some changes to commit. So I think everyone's logged into their developer orgs. Feel free to go and, make a change in there. You can do a custom field with some layout and profile changes if you like.
You can, write a simple Apex class or trigger if if that's that's your jam as well. We've got eight metadata types. They mostly cover everything to do with custom objects. We've got global value sets, profiles, layouts, Apex.
I think I think that's about it as well. So, yeah, if everyone heads into the developer sandbox and essentially make a change that we can then go ahead and commit.
So, yeah, into the Salesforce tab there.
I think you'll need to do that as well, Okay.
So, yeah, make make make any change you like in the dev work, basically.
So, yeah, it could be a a field change. Could be yeah. Yeah. Make make a change that we can a simple change that we can commit through.
Sure.
I don't know if this is the one that I should be making changes.
This seems to the correction on our Yeah.
It should should be the one you're logged into, so should be all good there. And, Jeb, Maxime, Alex, yeah, feel free to to do the same here, and then we'll we'll go ahead and get these changes committed in the pipeline, start moving them through and and create a release.
Okay.
Cool. Awesome. So, yeah, if you head back into pipelines, we'll then be able to grab these changes. So, for everyone on the main pipeline, it'll be exactly the same as you're you're doing here. This widget's gonna work out of the project.
But, essentially, all you need to do is click on the dev sandbox node. So the the blue dev sandbox, just click anywhere on the that's it. Click into that.
And we're gonna start to see we're gonna be able to create a new feature. So in the top where it says new feature here, If you click that button there, and then we should start to see some Jira stories assigned to you. Now folks on the call might use Azure DevOps work items as well. This will work in pretty much exactly the same way.
But we're using Jira in this case. Most users do. So there should be if you scroll down, it should be, a user one first issue. So feel free to pick that one.
And then this is gonna be tied to that user story that you're doing. So what we've done here is we're gonna create a feature branch for main automatically. You don't need to worry about that. It's gonna be named after your Jira story, in this case, using that naming convention that you can see there.
And then what we're gonna do is actually just pick up those changes from your dev org and commit them into this feature branch so we can propose them to go forward, in this case.
So, Maxie, Alex, you can do the exact same on the main pipeline, and, hopefully, yeah, pick the the story that you're working on, click new feature, and give me a shout if, if you need anything from me, and we can dive into it as well. So I would use Compare Now two point o.
If any of you folks are long standing GearSet users, you know, we've one of the key aspects of GearSet is the comparison.
We've just completely revamped revamped the UX and a load of functionality in this, and this is going I think it's just gone GA today.
And then the the old comparison will be sunset soon.
So this is effectively the new way to be able to to compare between your dev org or commit changes. So there's a few different ways that you can actually grab these changes. Sometimes you might wanna look at actually, okay, just what changes have happened in the last seven days between, my dev org.
It's on prod now. That's good to know. Already using it.
So, yeah, you can just choose last seven days. That's a really quick way to just filter what you wanna see here. A lot of people will do that.
Sometimes you might wanna just pick an individual item that you know. But in our case, I'm actually gonna recommend that we choose the pipelines workshop filter that we have as well. So if you choose the drop down from compared types, we can this is compared two point o. Sorry. Yeah. Exactly.
So we can pick up the pipelines workshop filter in this case, and then it's gonna grab those those changes for us. So it should start representing stuff pretty quickly, and it's gonna start grabbing some things.
So we'll just wait for that to grab the changes that you had. So I think there's some new items there.
So if you click on the new tab, got custom object. Just waiting to see. It's yours. Yeah.
Gear set pipeline enabled. Is that you? Uh-huh. Yep. Got it. Cool. And then do you have any dependencies or anything you wanted to pick up with that one?
So just if you go and open up the Chevron next to it, I think we're we we had some, layout changes related to this. Right?
Uh-huh. Yep.
Yeah. So if we click on used by, we should see the layout changes. The new one has never used gear set. You'll see at the bottom there, we have this layout view. We've just released a new view for flows called flow navigator, which essentially visualizes flow XML because flows are horrible to look at when they're in XML form. So any admins on the call, do go and have a look at that. Hopefully, it's gonna make flows so much easier to look at outside of the Salesforce UI.
And for layouts, we try and do that's really good to hear, Peggy.
We do try and simplify this. We're gonna try and do this as many metadata types as we can and then hopefully bring this into conflict resolution in other places too.
The other thing here as well is on the layouts. If you never use Gearset, you'll be able to pick just the individual changes. So I think if you scroll down, you might see yeah. So in this case, it's just one change. But oftentimes, you don't wanna overwrite the entire layout with other people's changes they may have made if you work in the same org. So you may wanna pick precisely what you're trying to deploy. In this case, there's no problem.
Cool. And I think you can just pick up the profiles and permissions. So all you need to do is just select that there, and then that'll pick up what you were trying to deal with there.
Cool. So if we hit next on this one, we should we've got about forty selected items here with all the layouts and profile, the FLS updates.
That's gonna do some problem analysis for us. As you folks have probably seen, no problems here. So we'll go to pre deployment summary.
Oh, there we go. And then, yeah, we can just hit commit changes on there. Sometimes you might wanna write a commit message at this point, but, no need to do that today, I guess.
We got about wish we could alter XML in gear set.
Interesting.
We, we've thought about whether we should let people alter XML. It always has to always has to actually, always have to be in the right format. So you've gone with being able to take individual pieces of XML from a large monolithic file. But, yeah, I'd be interested to see your feedback on that side.
Cool. In this case, we've just committed those changes, and now all we need to do is create pull request. So for any folks who are new to to Vergil control or, I guess, any of the terminology, pull request is just proposing that your changes are then going to be merged or moved into the next environment or branch in this case. So, usually, it's actually a point of review.
And, traditionally, it's it's where you do peer review or code review. Or if you're an admin functional review, ask one of your colleagues to check over, and often companies will have, yeah, a whole approval mechanism set up around this. But it's it's where you have your approvals and quality checks done. So we'll hit create pull request in this case. That's gonna be a real pull request in in GitHub. So anyone who's a developer who works directly in GitHub, you can go there and and use that UI, or you can stick in GearSet if you like here.
Some people have pull request templates, which means people have to write them in a certain way. So why am I making this change? What is the change? What other solutions did I think of? But in this case, we'll keep it simple. I think I've enforced that you have to put something in description. So you can just write a word in the description, then it will let you create it.
Cool.
And then that should be it. So once that has been created, we should start to see that, popping up in just a second. So if you click the x in the corner, then your pull request is already waiting for the next environment. And if we just click onto the main pipeline, I'll just check how, Maxime and Alex are getting on. So if you could just click where it says prod.
Cool. Yeah. There's already two pull requests, waiting on this one as well. So, Maxime, Alex, if you follow along with, Bizwidget here, you can promote your changes.
If you go to just the the project again, Bizwidget, we'll get your changes promoted and then bring them all together in a release. So once you click on this, this essentially gives you a view of that pull request. Giset's doing a couple of things in the background here. So first of all, we're gonna validate the contents of the pull request with the next environment to make sure it's, if we merge it, it's actually gonna be successful. And, you can enforce this as a a quality check-in in Git so that no one can sort of, just push stuff without a validation happening.
You'd also see there it says GearSet can merge this PR. In the background, there's a lot of, XML conflicts come up a lot, where Git is looking at a huge monolithic file, and it kind of is it's doing a kind of file by file diff when, actually, it might just be that there's two elements in different places, and it's not a real conflict. So we've added in, what we call our semantic merge algorithm.
It's it's a little bit misleading when we say merge because it actually just ensures that the the conflict never happens in the first place through our understanding of, XML conflicts between elements.
So there'll often be a lot of PRs that might actually say they've got a conflict in git, but in gearset, you can you can merge them.
If you did have a true conflict here, you've got a UI in gearset to be able to go and select which pieces of XML, which pieces of Apex, or even edit the Apex file in in in some occasions as well. But it doesn't look like we've led to conflict here.
Cool. So we can hit, the tick box next to your PR there because everything's passed, and we're gonna be able to promote changes.
And when we hit promote, that's gonna merge the changes into the project branch here and automatically deploy them out to the the next environment.
So we should see that happening in the main pipeline as well. And then we're gonna bring all these changes together in a release, hopefully, within the last five minutes. I think we're I think we're gonna manage it, hopefully.
Be cool. We'll just wait for that one to kick off.
And then I think Maxime, Alex, how are you getting on on the the main pipeline flow as well? All good?
I'm writing now.
Awesome. Yeah. Go for it.
K.
Awesome. So one's promoting. I think we'll have to wait while that's promoting for the other one.
What you can do at this point as well is if you click on the long term project, I can show you how we'll bring the, the long term project. If you actually just click on so, yeah, if you go into the main pipeline sorry.
If you just click on the actual project box rather than the arrow, so just yeah.
Basically, what happens here is any, anything that's been merged into the project branch then queues up here as things like sort of stories and and features that have been merged into that. What we'll allow you to do with long term projects is that this, again, might be building up over a month rather than your two weekly sprints or maybe six weeks. We allow you to actually, cut the entire state of the project rather than all the individual peat pieces and bring it into the main pipeline as one project PR, essentially, or project pull request.
So, yeah, essentially, being able to promote the entire project in one shot, because often that's what folks want to do. And then then you'll be able to push that into a release with the business as usual changes as well.
So I'm just I've I'm not sure that that, has merged yet, so we'll just wait for that to go and merge into your project branch.
Sure.
And if we just check on Maxine's as well yeah. So if you click on prod there, we can actually start to create a release as well. So we've got one item queued for prod. And you see against production, we have another option. So oftentimes, folks don't promote things individually into production, although you can. You might want to collect all of the features that you have paid for that release into a release branch that can validate altogether. And then when it's time for release, it's already validated, and you can just schedule that deployment log off, and that will go out later in the evening.
So, yeah, we've got both of them there. If you select both, you can actually click create release there. So I'd create release.
We can call this anything. Release is a fine name for this. Demo release. Yep.
Hit merge into release, and that's now gonna bring both those changes together into a release branch. They're gonna automatically validate not as the individual pieces, but altogether against production.
And then we can hit view release in this case.
And now you can see it's kind of one block in this case. So once that's all validated, you're able to deploy or schedule the release or or add more changes to the release in this case.
We'll just go and check on the the long term project. If you click on that again oh, no. If you just click on the box. Sorry.
That's my best no. That's my bad.
Cool.
Yeah. Anywhere on there.
There we go. You can create a pull request from the project here. In this case, there's only one feature.
But in a real scenario, you might have, again, like, ten features or features that have been built up over a month in the project. That's a milestone, and you wanna release that milestone of the project, alongside the other ones. So you can create a PR here, and that's gonna take the entire contents of that project branch, all the features in it, just as one pull request into your main pipeline that can be put into a release with everything else.
Cool. So I think we might be just about, on time here. If we hit, if we just click on production or the pull request rating for production, I'm just gonna get us to deploy the release so we can see how that works. But you if you actually just click on the arrow next to it, this is probably most useful for folks here. So, next to deploy release, there's, like, a little arrow with a drop down, scheduled deployment here. So this is all pre validated, and you might wanna set a time again. You may do out of hours.
You you may have particular times or windows that you deploy in. So you could set any time you like here and then schedule the deployment for release as well.
And we've just completed that in the absolute nick of time. Has any anyone got any questions before we wrap up, I guess? I think just to confirm what we've done today, we've created, all of our pipeline, all the different environments, so UAT production, the automation tools between them. We've committed some changes through and then brought a long term project in and and released them all together.
Anything anything anyone's scratching their heads about or any anything you'd like me to follow-up on if, via email or anything else?
Hey, Matt. I do have to drop. I have to recall, but thank you so much for this. This is really helpful.
No problem at all.
I'm just having a look at Peggy's.
Is there a recording, that shows non pipeline CIC deployments?
Yes.
I might follow-up with you by email again. You have my email, but I'm happy to hop on a call and talk through any of these these items.
There are just CI jobs as well, but they have a lot less functionality around visualizing all requests, and other things like that as well. So if if you're thinking about ease of adoption, pipelines is probably gonna be the the the best bet.
And, Alex, you're absolutely right. It does look easy. I'd say what the devil in the detail is is the prerequisites.
So actually getting your team ready for adopting something like CICD pipelines. It's like, you know, do do you have your orgs in sync?
Is everyone comfortable with the DevOps process or branching strategy?
Do you write your user stories in a way that's conducive with that? I'd say the actual technical setup, pretty simple. Just clicking a few buttons and doing the settings. I'd say making the decisions and doing the prerequisites before is always the thing that takes more time. It's the it's the people the people and process aspect. Right?
And, yes, I, I think we've got time for a question, and then I'll I'll make sure to wrap up for everyone.
But you delivered new code. You've updated the code and deployed updates.
In the case of a rollback, will the comp complete new code be deleted or the most recently changed one? The way GearSet works with rollback is we take a snapshot of the cheers, Alex.
We we take a snapshot of the kind of, the last state of that file in the target of that deployment. So if you would if this was an existing Apex class in production and you had released a change to it, when you roll back, you would just be able to roll back that change.
It's only if you deployed the absolutely new one that then you would be able to destructively change it, if that if you get what I mean. So we we kind of we're going from the state that you'd gone before in that deployment. So it's always based on what you did in that deployment and then reversing that individual deployment, if that makes sense, Sai. If you go to docs dot gearset dot com and search rollback, you'll find the doc there, and it'll explain all of the the mechanism for you.
Cool.
Alright, folks. Gonna make sure we wrap up. We're three minutes over. We got through everything today. Thanks everyone who actually dived in and, we're the users for the day. Hope it was useful. If you have any questions at all, my email address is here.
Feel free to, use me as much as you like. Ask any questions over email. Happy to follow up. And, yeah, have a great rest of the week. Catch you folks soon.
