Description
Watch our Gearset accelerator session where we talk about best practice and game changing features in Gearset.
In this video we walkthrough:
- Visualization: Get an overview of your entire release pipeline, with quick visibility of where your changes are in your release process.
- In-app merging: Promote changes by merging branches from within Gearset.
- Propagating changes: Automatically make merged changes available for promotion to other environments in the release pipeline.
Gearset Accelerator videos:
Transcript
Hello, everyone, and welcome to the fourth session in the Gear Set Accelerate Series. As a quick introduction, I'm Maroof, and I'm here with Hugh today. We're part of your customer success team at Gear Set. Some of you may have spoken to us, directly, spoke to us in the in app chat, or over email. Either way, thanks for joining. It's great to have you here.
Today, we're gonna be talking about Gearset Pipelines, which is functionality available as part of the Gearset automation license. A lot of our customers are already deploying through Gearset Pipelines to mature their DevOps process and further enhance their use of source control driven development.
To give you an idea of what to expect today, Hugh is gonna run through a twenty minute demo and talk to you about pipelines in Gear Set. He's gonna show you how through our UI, you can get an overview of your entire process with quick visibility of where changes are as they move through your release lifecycle.
You'll be able to see how you can promote changes by merging branches without ever needing to leave Gearset. You'll also be shown how you can automatically make those merge changes available for promotion to other environments in your pipeline, including being able to backpropagate your changes into lower environments, making sure that you can keep your orgs in sync.
As for any questions you might have, just pop them into the chat. We'll do our best to, answer you throughout, address after the demo, or reach out to you individually if we run out of time. And with that, I'll hand over to you.
Thanks, Maruf. I think I'll start off by actually sharing my screen. We can get eyes on nice and early on everything we're gonna be looking at today.
So, Maruv, can you confirm can everyone see my screen?
Yep. Oh, looking good with you.
Perfect. So in that case, I think what we'll start off with is actually just describing what pipelines is in Gearset.
The simplest way to describe pipeline is a series of connected automated continuous deployment jobs, each deployment moving through the metadata moving the metadata contained in a pull request from a branch to an org, all managed in your gear set UI. It's allowing us to easily visualize our process and work through it.
At each of these steps, we'll be getting visibility to changes going on in our process and have a few more benefits, which we're gonna touch upon throughout the demo as well, to make sure we're as confident as possible when we're ready to release to production.
The combination of webhooks, automated deployment jobs means that a feature can start in your development environment, enter the pipeline, and run all the way through to being deployed to production.
So that's what pipelines is. And I think the next place to go is actually looking at the branching strategy behind this.
But if I click over to a branching strategy here, which we call the expanded branching model in Gear Set, we can actually talk about bit behind the scenes. So we can split this into two sections. The first being this left hand side of our diagram where we're using the compare and deploy processing gear set to get the changes from our development orgs into these feature branches. And then the right hand side of our diagram, which is where we're actually seeing the pipeline promote the changes towards production via pull requests and CI jobs.
But let's talk through that in a bit more detail.
So as we've mentioned, this is a series of connected automated deployment jobs designed to get from a, development, all the way through to b, production.
And we start from the left hand side here where we want to get these changes into our pipeline.
This is done by creating a feature branch off of our source of truth, in this case, main or master, and using the compare and deploy functionality in GearSet to commit our changes from our dev sandbox down to this feature branch.
We can then create a pull request from this feature branch in GearSet to our next target, which in this example diagram is the long standing QA branch.
Each long standing branch is associated with a specific Salesforce sandbox in our pipeline and has a dedicated GearSet automated deployment job monitoring for changes made on this branch. This is essentially how GearSet will promote our jobs, promote our pull requests through to our orgs, and propagate our changes moving forwards.
It's at this stage where we're deploying it and wanting to put this pull request through to our org that Gearset's gonna be validating all of these changes, honoring any code or peer review process we have in place, and also helping you check for any merge conflicts to help you resolve these.
And that's something we could dive into a bit more detail when we actually push a change through my pipeline.
Once all these checks have been passed, we're confident that the deployment will be successful.
We can promote this change from the long standing branch to the connected org, in this case, QA, and Giaso automatically open that pull request against the next target in the pipeline for us. So in this example, UAT.
And this process is repeated for however many environments you have set up in your process as everyone works in a different way.
As we get close to production, we can then use the same method of promoting the change via that deployment job to production.
However, some teams work in a different way, maybe building up a release.
That's where our release branches come into play. So when it comes to promoting changes production, we can build out a release branch ready for that go date, ready for that release date as needed.
So with the branching strategy and kind of understanding what pipelines is, we can now actually go in and talk about moving a change through this pipeline.
So what you'll see now is how the visual aspect of that branching strategy we just looked at translates to the gear set pipeline on my screen. Here, you're getting kind of a graphical view of your process and have that visibility to where changes are at any point. You're gonna see these changes represented by these indicators.
Here, there are pull requests against the different environments. So there's three here, there's three here, and there's three at the end of the pipeline are all pull requests against these environments.
These green environments represent our long standing branch and environment pairing we just discussed in the diagram.
And as we mentioned in the branching strategy, we'll start on the left hand side here of our pipeline with our blue development environments, where we want to retrieve the changes we've made in our dev orgs before we get to these static environments.
So let's actually get one of these features.
To get this change, we're gonna create a new feature branch tied to a specific Jira ticket, and we can use the compare and deploy process to commit that change to our feature branch. So let's just click into a new feature here, AB ticket fourteen. You're gonna see that Gear Sets automatically populates the future branch with the ticket name, with the option to change this as needed following any naming conventions you might have.
I can then go through that compare and deploy process to commit my desired changes to this feature branch.
So just say I've already gone through this process, and have a feature branch ready for us to go, with a change already committed to it via this compare and deploy process.
If you want to see that compare and deploy process in a bit more detail, you can search through our document section in gear set. We have a new video coming out soon around that compare two point o, which will help reveal a bit more about that process there. So if I go back here, you'll see I've got ticket six ready to go.
So with the change committed to the feature branch, I'm now ready to create this pull request all within here in gear set. And this is going to my next target in the pipeline, my integration branch.
So you see currently I have three pull requests open against this environment.
When I press create pull request here, we're gonna see that jump up to number four.
So let's just give this some details and create that pull request.
In case it does the rest for me.
Then while that's loading through there, what we've done is this first section here where we have created the feature branch off of master, committed our change from dev to the feature branch, and created that pull request against the next target.
So let's take a bit of a deeper look into these pull requests that are open against this integration environment.
You see that pull request we just created, ticket six at the top here, being validated on the right hand side here. We've got a validation in process here. Give me an indicator of any issues that could be present ahead of promoting this change through to my environment.
The bottom section here is gonna be us servicing any peer review or other checks you have in your source control.
And then at the very bottom here, you'll see the ticket and actually the changes that are included in this pull request.
On the top, you're gonna see something we're gonna talk about in a bit more detail soon around merge conflicts and how these are handled right now. We're all good with this pull request. There's been no merge conflicts.
All the checks are passed.
So I'm confident that I can actually tick this box and push that through to my Salesforce org. So that automated deployment job is gonna take this change and promote it to my integration environment.
At this stage, I can include as many pull requests as I want, or I can cherry pick them as needed.
So I'm confident with this. So I'm going to promote my change through to my integration environment.
So while that's being promoted, I wanna take a deeper look at some of these merge conflicts and some of these validation checks and what happens when they aren't actually met.
If I just click into the pull request against the next environment here, you're gonna see I've got a pull request with a big old cross next to it.
This is showing that I have a validation that's actually failed for this, and this is tell me telling me that this change isn't ready to be promoted.
If I push this through, the deployment success is lower than I want it to be.
Specifically here, this is down to test failures. So this is setting up configuring gear set to act as a bit of a gatekeeping method specifically for my UAT environment.
Now that's validations. Let's talk a bit more about merge conflicts. If I go back to our pull requests here against my integration environment, you'll see I have the feature dev two onboarding and this SLA serial number pull request.
Now these both have merge conflicts associated with them. And when it comes to merge conflicts, we have two different conflicts that Gearset deals with in different ways. We have semantic conflicts and real conflicts.
So semantic conflicts are conflicts that the Gears set engine is able to resolve on our behalf, so on behalf of the user without any human intervention.
So with this feature dev onboarding here, you see gearset is flagging to us that our version control might display a merge conflict.
However, was able to resolve this for us, and we could proceed with promoting this change with no further intervention as that's all been solved for us. However, if we look at the SLA pull request here, the difference is real conflicts are conflicts that can't handle for you. These have a specific action that needs to be taken by by us, by our team.
However, what we are gonna do is try and give you as much information and an ability to resolve this within Gear Sets UI. So we don't have to jump out, don't have to go to our source control at all. I just press view and resolve conflicts here.
You're gonna see this is highlighting where that conflict is, what it is, give me option to pick and choose what I want to do to resolve this change for me.
Now you'll see that that ticket six has now actually been promoted to my integration environment. And what's happened here is this number three that we had previously has jumped to a four. That's because GearSet is automatically for me. Open that pull request against the next environment.
So you will see here that ticket six is already ready to go to our next environment.
Gear set's already gone through those same checks against our UAT org, that merge conflict, validation, and any source control surfacing any source control reviews that we have on our end.
So, again, if I'm confident that this can go through with all these checks having happened, I can, again, tick this box and promote that change as needed. And what we're gonna see here is this number three against our final environment production is again gonna jump up to number four. That's gear set. It's gonna open up that pull request for us, making this a bit more of an automated process for us while gatekeeping and keeping our checks in line.
And let's push that through.
So that leads us to our final environment here, production. So kind of a kind of a big thing in our process is getting these changes through to production. It's kind of the whole purpose of this pipeline.
If we click in here, you're gonna see we have the usual action we can take of ticking these through and promoting these changes through to production with the usual checks that gear sets running for us.
However, maybe we work in a different way. As we mentioned during the pie during the branching strategy, some teams like to work and build up a release.
So we can have a release branch running against our production walk here. So that's on main.
So you see here, I actually already have a release branch created with a few changes on it. So with this, I can easily deploy this release as needed if this is ready to go. Those three pull requests, those three tickets are ready to be promoted to production, or I can simply add to this release. So let's say ticket seven is ready to be bundled in with these.
We can merge that into the release.
And what Gear Set will do is continually validate this release branch against production as I add changes to the release branch.
They come release day. I'm confident in my deployment success.
You can see that's gonna be included once that's pushed through there.
Now this change here, the one we've just pushed through so as you can see, these checks now being added as we just added ticket seven.
Now with ticket six, the change we've just pushed through, you can see that's been promoted through to my UAT. That pull request is automatically opened against production, And, again, we're running through these checks.
The merge conflict, that validation, our status checks. And this is especially important on this final environment as we're pushing this through to production. So this is going live to our users.
So we'll let that run, and we can focus on ticket eight here.
So, for example, if this one isn't part of the release, this is a change that's ready to go through production.
We can just straight away promote that change through to production and allow that change to go through.
And once that has gone through, we can start talking a bit more about how we can look at back propagation.
I think, Maruv, if we have any questions, we can start answering one or two here.
Yeah, Hugh. So while you were, talking about the, merge conflicts, we had a, question pop up, actually.
Someone asked, as an admin, do I ever need need to leave Gaysert?
Of course. So it's a good question, and one that we get from a lot of maybe more mixed ability teams, teams that might not have as much source control experience.
As you can see, the the process I just went through from a, getting that change all the way into the pipeline and then all the way through the pipeline, I didn't have to leave gear set once.
So we're surfacing a lot of that source control side for you in a bit more of a graphical way. Maybe a bit more maybe a way that's easier to digest and and work with, than some people might be used to in other roles.
Yep. Perfect.
So what you'll see here is that chain, that ticket eight that we just pushed through has gone through to production.
Now you'll see here that I have a hotfix static environment here. It's not directly in the pathway of any changes going through. However, it's pretty key to me that this is kept up to date and in sync with any changes going through this environment.
You'll see that I have a couple of back pointing arrows here. So a couple of pull requests going the other way, going downstream.
If we click into those, we're gonna see that change we just promoted through to production.
Here, it automatically recognized that this isn't included on this long standing branch or committed there, and it's gonna give me the option to promote that through so I can keep this hotfix environment as in sync as possible.
And that's the same for our development environments or any downstream environment, really. You can customize that setting within your own pipeline to how you want to push this through.
So just to go back to where we started with this demo and looking at the looking at the branching model, we picked up a particular Jira ticket in gear set. We created this feature branch and committed our changes from our development org to this feature branch all within Gearset.
In our pipeline view, we're able to create that pull request and promote it through to our subsequent branches, and these deployed them automatically out for us while after all those checks have gone through to our QA, integration, UAT, however your setup is. And then finally, we push that through all the way through into production, but also built out a release branch if that's how your team wants to work.
So, overall, we've gone from having a change outside of our pipeline to pushing that in your development environment and all the way through to production in the fifteen, seventeen minutes we've had here. And that is everything from a to b, really.
I think if we have any further questions in the chat, we can go through those now.
That was wonderful. Thank you for going through that, Hugh. We have had a few more questions pop up.
So one of our users has asked, when setting up pipelines, how should we best handle work that's already in progress?
Yeah. It's a good question. One, we come across a lot with teams wanting essentially wanting to adopt pipelines, but no one not everyone's starting from scratch all the time. You quite often have work going on.
One of our recommendations with this is any releases in process or any work in process or progress. Sorry.
Any changes are pushed through to production.
Refresh these lower environments. So, essentially, you're working kind of from a square one there. The most effective method to allow you to build up this pipeline and integrate this process as needed.
I think if I pop over to our document section here, and we pretty sure we do have a document based around this that I will put in the chat for everyone if anyone wants to save that link.
This document talks through that in a bit more detail, and it's useful one to save if you're looking to set this up.
Brilliant. Yeah. That's a great tip there in terms of keeping hogs in sync.
We have had another question, which is earlier in the process, actually. So what metadata types should I include when setting up in, setting up the pipeline?
Yeah. A lot of questions around setting up pipelines, and, it's a good thing to cover quite early on. So the advice we kind of put forward from our team is the metadata filter you're using to set up your pipeline kind of dictating what's included, you want that quite wide and encompassing as possible.
You don't know what changes you might be working on down the line. You can kinda future proof for that.
However, within that, it can be seen as kind of a best practice to exclude metadata types that you won't ever be touching or being used by your development team or included in the process.
Best way to you best way to describe that is maybe removing some clutter from the repo and from that work.
Again, the wonderful support team on our end have included quite a lot of quite a lot of documentation around this. So if I, if I think that's data and pipelines, we should have another document around this that, again, I'll post in this chat here.
Thank you, Hugh. We've just had another question pop up just now, actually.
Is it possible to include profiles in the pipeline, including the permissions they have on objects, on fields, on layouts, on apps, and so on?
Excellent.
Great question, Kjell. It's one we do get quite a lot, and it is possible.
Again, I want to defer a little bit to the documentation here as I know profiles permissions could be quite a beast, within Salesforce and within a lot of the work.
So it is possible. What I'd want to do is, again, profiles permissions is I want to be able to give that question justice and give you the right information straight off the bat. So, Cheryl, if I'm what I'm gonna do is follow-up on that question with you after the demo, and we can share that within any follow-up we do from this demo as well with everyone, just so I can give you the right documentation around that and the best practices we can we can advise.
Thank you very much, Hugh.
Yeah. As Hugh said, we're going to, we've got access to all the questions that have been asked today, and we'll follow-up, follow-up with you all individually.
And with that, I'm just gonna give it another second or two in case there's any other questions.
But, yeah, I guess, on that note, we can kind of bring today's session to an end. So, yeah, thank you for joining this, this accelerator series. I hope you've all found this session useful.
Whether you've have additional questions about pipelines, automation, or anything else in GearSat, you can contact you, myself, or the rest of your customer success team by emailing success at GearSet, dot com or by dropping us a message in the in app chat.
We'll be in touch with you all very soon about the next episode in the accelerator series. In the next webinar, we'll be showing you how you can use Gearset to see data to your sandboxes and mask that data. But until then, thank you for coming along today, and, have a great rest of your day.
