Description
Watch our Gearset accelerator session where we talk about best practice and game changing features in Gearset for continuous integration and version control.
In this video we walkthrough:
Automation processes: Gain insight into how you can improve your DevOps maturity by automating your deployment processes in Gearset, leading to higher quality and faster delivery of features to your business.
Collaboration: Learn how you can track team changes and allow team members to work on multiple projects with parallel development streams in Gearset.
Gearset Accelerator videos:
Transcript
There we go. I think with that, let's get stuck in. So hello, everyone, and welcome to the third session in our GSI Accelerator series. Just as a quick introduction, I'm Hugh. I'm here with Beth today, and we're part of your customer success team over at Gearset.
Some of you may have spoken with us directly, in calls, in the end in app chat or over email, but it's great to have everyone here. Today, we're gonna be talking through and going through CICD functionality that's available as part of your gear set automation license.
We have a lot of customers that are using that to mature their DevOps process and start using source control driven processes.
So we'll be running through a short twenty minute demo around that today, and we're gonna be targeting and talking about an example of a branching strategy that you can use, a lot of our customers utilize today. And then we're gonna go into some key functionality to help you explore burst control and CICD, such as actually setting up those CI jobs in GearSet and seeing what those are used for.
As for questions, there's no formal process, so just pop them in the chat throughout, and we'll do our best to answer you either on the fly or we have a dedicated section at the end of today's demo to go through those. But that's enough for me. I'll hand you over to Beth who's gonna take us through the demo now.
Awesome. Thank you.
Hello, everyone. My name is Beth.
I'm part of your customer success team here at GearSet, so lovely to meet you.
So like you said, today's demo is going to be looking at kind of your CICD within gear set and also how version control kind of plays a part in that. So what I will do is start sharing my screen to give you a little bit more context and get this started.
So brilliant. There we go. So let's start at the very beginning.
Those who are familiar with the compare and deploy, you've probably attended one of Hugh's, past webinars.
What CICD means is essentially a compare and deploy.
It's exactly the same, apart from that it's automated.
So there's less manual intervention.
I suppose the benefits of that is to have quicker deployments, higher quality, features also delivered, and incorporate that collaboration within your team, through the use of version control.
So before I show you how to set up any of the CI jobs, I'm gonna give you a little bit of context, show you one of our branching strategies that he said, you can utilize and give a nice little, background as to how this may look like within your team.
So this is one of the bunch strategies, again, that you can utilize.
The story today is perhaps, I'm gonna be one of your release managers. Okay? So I've got my admins and my developers working.
I've incorporated version control within this workflow. So I've tasked with all my admins to create a feature for me, and this might be a pick list, custom item, whatever it may be, I've assigned that to them. So start at the very beginning.
We are going to be looking at the master branch here at the very start. So what a master branch essentially is is going to be your source of truth, And a source of truth is going to be an exact copy of what your production will look like, with the intention that whatever feature that you create, whatever feature that you want to test with, it's gonna be a copy of your production. So, all your features will be kind of tried and tested, and it will will look and reflect as well as it can do in the real live environment.
So we're gonna start again. You're at your master branch. We're gonna create a feature branch with which is an exact replica of your master branch. You just copy and paste it, essentially.
One of my admins has created my feature for me. They've done that in that, sandbox, and I've tasked them to do that's all fine. That's all created. Perfect. So how are we gonna get that into production?
What they're then gonna do is they're gonna commit that feature that was just created. So essentially transport that feature into that, feature branch, which again is exactly copy of your production, your main.
Once they have done that, which has been put into my feature branch, I'm going to create a pull request. I just wanna highlight that this can all still be done within gear set. So going back from your compare and deploy page, you could create feature branch off there as well. So there's really not too much that you have to deviate from within the platform, which is great.
So, yes, they've commit that change into their feature branch. I've created a pull request. Now this element here is the only part that you really have to go outside, of gear set. So this is where you'd have your code review, any checks that you'd want to be done before this gets merged back into your master, that is where you do so.
So I've checked that that feature is working as it should be, or I'm quite happy that everything that I've requested for them to do is as it should be.
I'm then gonna merge that into my master. So that feature has gone from being separate to my master back in.
What that will then mean within gear set is with our CI jobs that will run, which I'll spell more as we we create those jobs, is that we'll have automated jobs that will run that you can set that say, okay. I've noticed the change within your master branch. I'm gonna run this job, so I will happily deploy that change for you into your testing environment. And above here, we've got our QA, our UAT.
And once you're happy with that, and, again, depending on how you kind of create your your CI jobs, I'm happy that that feature is tested and tried as best as it can be. Let's move it into production. Let's go ahead.
So that would be one of our CI deployment jobs that I've just spoken about there with that automation element.
I can then also create a continuous integration validation job here.
So what that will mean, which I can explain, is that it will validate this, and then I can manually say, okay. Before it goes into production again, I've tried and tested. It's looking as it should be. I'm gonna give that the go ahead and deploy that straight away.
So that is a very brief overview of what this certain branching strategy will look like with version control and how gearset will help with that workflow as well.
So let's go into gearset and let's see how these jobs kind of work and how they play out.
So all we need to do is we've got our homepage here, our compare and deploy. We're just gonna go to the site here and go under automation into continuous integration.
Now it's gonna look a little bit busy at the moment because I've got a lot of jobs running, but I'm just gonna filter that down here just so it's a lot less noise.
So let's go into creating our deployment jobs. So this is our dashboard here just for, just highlighting it here just so you can see exactly what jobs are going, and you've got your validation deployment here as well. So let's get into creating a job. So just at the top right here, we've got the little button here, add a new deployment job, which is is exactly what I'm gonna do.
So let's start at the very, very beginning. You've got a job name and you can name this job to whatever you want it to be and it could be descriptive. So perhaps it might just be simply what your source is gonna be and what your target is. It's completely what you choose it to be.
I'm just gonna call it my CI demo just for ease.
Now with CI jobs, you can have org to org, but for the premise of today, I'm just gonna show how your version control, and git works within this role. So my source type is gonna be my GitHub, which I've linked up and hooked up before within my Salesforce. It's gonna pull through that source repo and that source branch here. So I'm happy that that's exactly how it's going to be. That's the source I want it to be.
Our target is going to be an org for me. So it's, again, very similar to those who are familiar to compare and deploy. You choose your source and target. It's exactly the same.
So following off my user story, I'm going to have it as production.
Alright? So the next screen that you'll be, following along to is kind of explaining the settings that you'd want it to your CI job to run.
So as I explained kind of going through the feature branch model, you have two CI jobs that you can choose from. You've got deployment and validation.
With deployment, to consider it a automatic push of changes from your source, so in this case, my my repo, into my target org, which is my production with no intervention. I don't need to have any kind of oversight here. That's gonna do that off its own accord.
Where validation differs is, it works very similar to a deployment job, except you will manually go into gear set and select deployment. So, again, in my case, I don't want jobs to kind of run off automatically into production. I wanna have an oversight there. That's when you'd select your deploy, and you'd that will go straight in there. So that's only the difference there. It's not too different.
Synchronization type. So how would you want your jobs to run?
You have two types here. So you can have a full sync between your source and target, if that's what you say you wish to choose, or you can have something that we'd call Delta CI. And what Delta CI basically means is any changes. So that could be new, deleted, or changed items.
I want my job to only run when it detects a change. So that's what I'm gonna choose for today. It makes sense with my source control.
Now when is the job gonna run?
You can choose when the source branch is updated.
Again, we use following my user story.
Makes sense. So what I've know that my admins or developers have merged the change into my, my, source source repo, that's when the job is going to start off. But you have the ability to choose it either every hour up to twenty four hours. It's completely how your team decides to work.
You can then also include kind of your pool request. So you can validate your pool request targeted to the source branch, send notifications, pool request validations. It's really up to you. It depends how your team works.
Now the differences that you'd want to deploy, we'd recommend to include deleted items just because we know that that is also a recognized change. So if you want everything to be pushed through, we'd suggest to include that deleted items in that job so you you have that full comprehensive reassurance that everything's working as it should be. And you've also got the bottom here, include user permissions to deploy to which you can also add into that job.
So that is a very basic settings of what this job is going to look like. If we go on to the next page here, we can then incorporate unit tests and automated UI tests also within this job.
So I could say for this job that ask I want my default Salesforce tests to run alongside it. That's absolutely fine. You can also say you want all your tests to run, specify tests run, and don't run any tests at all. It's completely your preference.
But say I want to specify which tests to run, I have the ability to kind of cherry pick what kind of tests that I'd like. So test classes, test suites, Apex changes, and anyone that, match naming conventions. It's up to you. You can really have that granularity over in the CI jobs. But I'm just gonna, choose my Salesforce default tests. And also those who use automated UI tests, so XLQ or eggplant, you can incorporate these within your CI job as well. But I don't have any at the moment, so I'm not going to.
Now the next one.
Again, very, very familiar, and very similar to our compare and deploy.
You have a metadata field here.
So, essentially, what this metadata filter will do is kind of any items, that you'd want your job to pick up. So if you've got perhaps items that you work on regularly, that is what this job is going to kind of capture and push through. So this is where you can pick and choose what you'd like to, for that job to incorporate.
Lovely. And, again, similar to kind of the tests, we've got our static code analysis that you can also add within your job. So you can have a gear set standard rule set if you so wish, or you can choose kind of depending on what you you folks want.
And also you can have those kind of barriers, to what those tests or those outcomes will be. So you can fail the run if that static code analysis are detected. If I say you wish to turn that on, you could then choose on you can just fail the runs on those errors and warnings or just errors only.
So, again, depends on how you folks work, but I'm not gonna include that today.
And those who want to incorporate any outgoing webhooks, this is the the part of the CI job that you'll be able to do and include those in as well.
So, again, I keep referring back to the compare and deploy because it's exactly the same. It's just, less intervention here. But those, who are familiar with those component deploy, functionality, you'll probably recognize the problem analyzers that you get hit with to kind of say, hey. This might work.
It might not. Add them in. Don't add them in. This is exactly what it's doing.
So you can say, right. This job is running. I wanna apply all the fixes that Geasset is suggesting Might, increase the likelihood of a successful deployment or don't apply any fixes at all. It's completely up to you.
But I trust Gearset, so I'm not gonna apply all these fixes.
And then you've got your notifications. So to really get a good awareness of what's going on and when you'll be able to get notifications sent to you kind of on any everyone or perhaps you're only interested in when the CI job fails. It's really up to you. And those results can be sent to you either to email, your text message, Slack integration, Teams, or Chatter.
How your team works is completely dependent on that.
And that is exactly how you set up CI job. It doesn't take a lot of time. I've saved it now, and it's all in my dash dashboards here. So I'm just gonna again reduce that noise because I don't wanna see all of that.
And now I'm gonna show you what this means, what you can do with these CI jobs.
So I've created a job earlier. So with the job name, I've just been quite descriptive of what it is, and I can also see the source and target. So you've got that overview there. You click on the job, and you have different options for what you can do with this as well.
So you can convert to see a Teamshare job. You can duplicate the job, edit the settings, webhook setup, copy ID. So perhaps you might want to edit, maybe your metadata field setting your job that you created. It isn't concrete.
You have the ability to edit that as well.
So what does this history look like? So I'm gonna view my history here, and I'm gonna go into all times. I haven't had many recent runs. So you have the ability to kind of change the dates there. And this is what my deployment CI job looks like and kind of where those problem analyzers, those code issues have been picked up.
So it gives you a very comprehensive overlook of what the job or when it ran. Sure. Excuse me.
And it gives you a good view of kind of what's happened within that one as well. So from the twenty fifth of May, I had a successful deployment job result, and I've had six changes within that run.
And just to break that down a little bit more for you, I had one change metadata item, but it also had five new and nothing deleted. There was no problems that need to be or problem analyzes that need to be applied.
No code issues.
So it was a very sound deployment, which is great. I can see exactly what's happened, and have that knowledge of, right, this is what's happening, even though it is automated. So it's less intervention from yourselves.
So going on to validation because, again, there is a little difference and there is that, intervention from yourselves if you so wish to have a bit of oversight, bit of control as to what's going where. So I'm gonna go back to my jobs here.
Now my validation, again, it's highlighted kind of here between the two jobs here. It differentiates.
I have got one here that was set up earlier, classic Blue Peter style.
And you've got the same settings here as well. So you can convert this team shared, transfer the ownership if you so wish, duplicate the job, edit settings, copy job ID, and webhook setup. It's all exactly the same.
So I've got a job that's running under the validation, CI job. What's it look like? We're gonna go exactly the same, view the history. Again, go into kind of all the runs that this job has completed for me, and you get a nice little overview of what's happened and where. And it's good that I've kind of kind of done a validation job here because you can see that some of these have failed.
So with those who kind of want a good comprehensive oversight, this works perfectly.
So, unfortunately, my last my bottom three haven't worked out for me. What a shame. But my top one has. And this ran, again, on the sixteenth of May. You've got a time stamp there. Also, the source commit as well within your version control. Just getting a little extra bit of information.
And you can see the results here has exceeded. Fantastic. And, And, again, it's given the attempt to change is just the one, and it'll be a new metadata item to which you can kind of view in the comparison if you so wish and also view the summary.
I'm content that I know what this is, and I want to put this into production.
All I need to do now is just click this deploy button here as it should. There we go. Once deployment starts, you can't cancel it. That's fine.
I'm happy with that. And it deploys, and it's exactly like your confirm deploy page that it will send that through. Alright. Unfortunately, this one's to fail because, of course, on demos, it never works properly.
But that is exactly what you do within a validation.
And that is a very brief overview of kind of how automation works in CIC. So just to refer back to our branching strategy as well, that so I created my my feature from my my my app and created that, deployed it back into that feature branch, committed that change, happy with the code view here.
And then because I set up my CI job to run when there is something detecting something new, something changed, that's automatically run, and that's gone into my UAT.
Perfect. That's gone into my, testing environment.
Then, again, with my validation job that I've just shown, just want that oversight because it is going to my production. I'm a bit wary of that. That's absolutely fine as well. All you need to do is just click deploy, and that is all the intervention you need to do. And with all within gear sets, all with in house, just except from that little code review part here.
But, again, that's kind of high quality, features that get deployed quicker and enhances collaboration within your team.
So have we got any questions at all here about this CICD within Gear Set?
We've had a few come through in the chat. The first one is from Forum around the setting up the, jobs themselves.
Mhmm.
We've answered it in the chat, but I think it'd be nice if we could just have a visual on that.
The question was, essentially, what do we select to set the target org as again?
Yeah.
And if we just head to setting up that new job, Beth, I can Of course.
We'll go with the deployment job here. So we'll look at the demo. So source type. Again, I'll go with my version control here and the target type here. So you have the ability to kind of pick and choose which is your your target.
Perfect. And, as you mentioned in the chat forum that that target org, is kinda dependent on your kind of branching strategy, your process. So that can be whatever org you've essentially connected to Gearset.
So I hope that visuals helped answer the question as well.
Now we got a few more questions. The next one, again, being linked to setting up the jobs. Mhmm. It's around Delta CI, and asking if this works for the validation only jobs.
Yes.
We get that question asked a lot.
But really the answer or simple answer is no. Only because Delta or how have been playing around with this a lot because we do get, again, this question asked, quite regularly.
And we haven't found or fine tuned a way to really make validations work within Delta CI only because with Delta, with the deployment, we have concrete kind of evidence, if you will, that we've seen something has been successfully deployed with where it's a metadata that's been successfully deployed into an or into your target.
There's not gonna be any kind of hesitation there.
The only differences within a validation is because there technically isn't any metadata deployed. It's just checking if it will or will not work.
Gear set at the moment can't kind of determine when you'd want those changes or where those changes would start.
So in short, no. But it's definitely something that we're kind of working towards to kind of get fine tuned.
Perfect.
Let us know if that answers the question. But, brilliant, the next one is in relation to the feature branch model that we've gone through today.
They've mentioned that their release cadence is quite slow. Just asking if there's any limitations around this specific model.
Yeah. Of course.
So, again, this is just one feature bunch model that Gear Set supports. So in kind of looking at this with that lens, with those who do have a solar cadence, probably, perhaps isn't the best choice only because, speaking about our master here, so using that, the keyword of a source of truth, and it's a source of truth because it is a a reflective, copy of your production.
So with those that perhaps have a a slower cadence, that master, that source of truth probably isn't gonna be in sync, to the best of the ability. So kind of think about best practices on. However, again, this is only one branching strategy that Gear Set can kind of utilize when you're working with version control.
So this isn't kind of a one size fits all. This isn't prescriptive. There absolutely is plenty of other models, for you folks to use. So if you are a team that kind of has a slower slower cadence, although this might not be perhaps the right one for you, there's gonna be another option there. So you can still incorporate that version control and with gear set with CICD within your workflow.
Perfect. And I think we just have one more question here. Just find that.
Ken, I think it's linked to the deployments of the jobs themselves. They're asking, do we run do you run any static code analysis and problem analyzers on on every deployment?
Of course. So what I would do, again, you have the ability to kind of edit the settings here as well. So just kind of highlighting that there. So on this job, for example, I'm just gonna edit the settings here, and you can see that you've got the static code analysis that you can apply here and, again, you can change it just as if you're creating the job itself.
And also you've got that problem analysis that you can either apply or not apply any of these fixes. You have the ability to control exactly what's going on.
Perfect. I think that's all the questions I can see in the chat right now.
Happiness.
So I think I'll wrap this up then Absolutely.
A little bit ahead of time. So that brings us in to the end two of our CICD gear set Accelerator episode. I hope today's session has been useful for everyone.
As a reminder, you can contact Beth, myself, the rest of the customer success team you have at Gearset by emailing success at Gearset dot com. If you have any final questions or if there's anything else we can do to help you and work with you on, to get the most out of Gear Set as a platform, then feel free to drop us an email. And you can also reach out via the in app chat. We can, chat there as well. But thanks for coming, everyone.
Keep an eye out for our next invite for the next session where we'll be diving into the next stage of automation and looking at the pipelines feature of Gear Set and how that can be leveraged similar to this session today.
But other than that, we will be chatting to you soon, and have a great day.
See you later, folks.
Bye.
