Description
Keep your pipeline running smoothly.
Transcript
Let's get going. Hi, everyone, and, welcome to the second session in the Gear Set accelerator series.
As a quick introduction, I'm Ruth, and I'm here with Charlie. We're part of your customer success team here at Gear Set. We're also, joined by Antonio.
Antonio is one of the onboarding managers here at Gear Set, and he'll be here to answer any questions that you folks might have for us today. So today, we're gonna be taking a closer look into Gear Set pipelines. As a reminder, last week, we spoke about some of the benefits of version control, some prerequisites, and considerations before setting up a pipeline, and Charlie walked through how you folks could set one up.
This week, we're gonna show you how to use your pipeline. So we're gonna walk through how you can start your user story within the Gearset pipeline, how to propagate changes forwards, backwards, and across your, different environments, and how to deal with any merge conflicts without needing to leave Gearset. If you have any questions, then please feel free to drop them in the chat. We'll do our best to answer you during, or after the demo. And if we run out of time, we'll be sure to follow-up with you afterwards.
Now before we get going, I've got a quick announcement.
Our product team are currently looking into improving how you can set up a pipeline within Gearset. So this is to ensure your setup is seamless and, you have probably set up your pipelines for you and your team. Now we'd really like to hear any feedback that you have on setting up a pipeline so you can expect to receive an email from someone in the product team in the next couple of days. If you're interested in chatting with us, then there'll be a link for you to book in a thirty minute session, and, you know, your input will play a key role in helping us improve gear set better to meet your needs.
So, yeah, we look forward to hearing from you. But that's that. Let's jump back into today. And with that, I'm gonna hand over to Charlie.
Thanks, Maroof. Let me just make a start, and I'll share my screen. Can we all see that okay?
All good, Chavi. Yeah.
Sounds good. Lovely. So as you can see, this is your pipeline is set up. What are we doing next? So once you've completed your gear set pipeline setup, as we spoke about in the first episode of the series, you're all ready to start your first user story using gearset pipelines.
So by now, your pipeline should be looking something slightly like this. You have your blue developer box sandboxes here on the left hand side where you make that initial commit, and you have green static environments, which are CI jobs that carry changes from your environment branches to the orgs.
So as Maruv said, pipelines consists of a few different core features, and I'll make a start talking about these now.
So firstly is how to use metadata filters. So metadata filters are the categories of changes that you are interested in moving.
So firstly, you have to pick a new user story. So what is a user story, you may ask?
If you have Jira or Azure work items linked, then you can select a ticket from the pipelines view, which I'll show you in the demo. And this is the start of your user story. A story that will go from the beginning of your pipeline and your dev box all the way to production.
If you don't have Jira or as your work items, don't worry. You're still starting to use a story. There will just be no ticket attached, but it still works in exactly the same way.
So what I mean by starting the user story is that the initial commit that you make from the dev sandbox into the feature branch as I spoke about in the previous webinar.
So initially, use the saved filter from your CI jobs. These are just a few little tips, to help you get started.
So once you've made the pipeline for your first commit, we recommend using the same filter that you use to create your CI jobs. This is so that you can get used to the commit process and also acts as a reminder to use a metadata filter that is certain that contains all the metadata types that you have in the CI job filters as well.
Thirdly is avoid types not included in CI jobs. So as I just said, including metadata types in the original commit that are not within the CI job filters will cause issues, and your CPRs that do not contain those changes that you have made. And then the final tip is once you're comfortable, with that initial commit and the metadata filters that you need to use, and the concept of filtering, then you can reduce the selection within the metadata filter. For example, if you're not looking to compare any Apex classes today, the likelihood is that that type can be removed from the particular comparison. The smaller the selection, the quicker the comparison will be.
What you can see at the bottom there is the image of the dev sandbox where you'll make that initial commit as we have been discussing.
The second part that I'm going to talk about is forward and back propagation.
So let's start with forward propagation. So forward propagation is how you will push the pull requests through your environment branches and environments following the initial commit from your dev sandbox.
What is backpropagation?
So in the context of gearset pipelines, backpropagation is the process of keeping lower environments in sync with the latest changes that meet that reach main slash production.
So for normal changes propagating through the pipeline, back propagation is only required in the case of multiple dev sandboxes and or to the hotfix org if you do use one.
For changes from a hotfix environment, all our environments will need to be backpropagated to.
So this leads me nicely onto the next point, which is backpropagation to dev sandboxes.
Sorry.
The first one being, the back propagation to dev sandboxes. So this is a feature that we recently recently released. This means that you'll be able to synchronize your sandbox directly with promotions happening to your base main branch, as you can see in that screenshot at the bottom. So these attract as updates, and as you can see here, this is an update from your main branch that will be going back to that dev sandbox.
If you're worried about work in progress in your developer sign box, even items that have not yet been committed will be protected when synchronising.
So at any point in time, Giset will detect and capture your work in progress from your developer sandbox that will be affected by the update.
It will allow you to use Gearset's merge conflict resolution UI to merge with changes coming back without overriding critical work in flight.
And finally, how to back propagate hotfixes in pipelines.
So hotfixes within pipelines are those which have been made directly into a hotfix org and pushed into production via a merge with the main branch. As discussed in the last webinar, changes made directly into an environment will not be picked up by the pipeline.
And in this way, there are kind of two methods to handle hotfixes if you do have a hotfix environment.
So firstly, you can individually hand handle each back propagation PR, which I'll show you in the demo. As we detect when changes are missing from a certain environment, we'll automatically open a back propagation PR for each individual PR that's being promoted. You will then have full control over what changes get back propagated and when.
Secondly, if you're looking to just back propagate all the changes at once, using the sync PR function will do just that. I'll also show you what that looks like later in the demo. So it'll just it will stage a PR containing all commits that currently exist in main that don't exist in the environment branch you're syncing with.
Once you've merged that, we'll close all the open back propagations as they're now irrelevant.
So the next slide is about conflicts and how does the conflict happen. So in essence, it is, two divergences from the same common ancestor.
Merge conflicts arise with the use of git.
It's a situation where there are two competing changes to the same line of code within a single metadata file. A conflict is valuable as it's not always clear which change is the right one. And in these situations, manual intervention is required when you'll need to pick and choose which changes to proceed with.
So how do we avoid merge conflicts? Merge conflicts are an integral part of any normal development workflow.
Realistically, it's not possible to avoid all conflicts, but it is possible to significantly reduce them with a few considerations.
In a perfect workflow, there are a couple of things you can do to avoid them most of the time.
So firstly, you should always create your feature branch from main. And secondly, you should segregate your deployment work appropriately to avoid overlapping work within multiple over go ongoing tickets.
The final point here is what does Gearset do to help resolve merge conflicts?
So if Gearset does, if Gearset does, pick and see that there is a merge conflict, we'll use our industry knowledge that there are some conflicts that we are able to resolve without the user's involvement.
So gearset pipelines knows that your VCS contains Salesforce metadata and uses this deep understanding of metadata when checking your pull requests for merge conflicts.
Merge conflicts will only happen when multiple changes have been made to the same XML tag in the same file.
When some of the changes within the same tag are conflicting but result in the same behavior in a Salesforce org, Gearset will automatically resolve that merge conflict.
This approach means that you'll sometimes see merge conflicts in your version control, but won't see the merge conflicts within Gearset or vice versa. And I'll show you an example of this in the demo.
If Gearset does detect a conflict, there are kind of two ways, built in ways to resolve them. Firstly, a standard conflict resolution where on a file by file basis, you'll be asked to accept these changes from either the source or the target in its entirety.
And secondly, with precision conflict resolution, where within a single file on a conflict by conflict basis, you'll have the option of picking and choosing which changes from either side you'd like to proceed with. I'll also show you this in the demo.
I'm just gonna have some water because my mouth is very dry.
Okay.
So let's talk about beginning my user story. So now we've got a good understanding of the theory behind how gearset pipelines can be used effectively. Let's make a bit of a start with the demo.
So as you can see, I've made a new custom field within Salesforce, and I'm now going to go to gear set pipelines and start my user story.
So I'll escape that and go here. Hopefully, you can still all see the pipeline screen.
So the start of my user story is going to begin here in the blue box in the dev sandbox. I'm going to create a new feature branch.
And because I've been assigned a ticket through Jira, I can see that, this new custom field is what I've been told to do.
I'm then going to press the compare now button, and this is gonna open a comparison between, the source and the target.
Now I know that it's a custom field, so I'm gonna come down here to custom field, and I'm gonna press that there and compare just that metadata type.
So I can see that new change here. I can have a look at the topic, and it was ready for onboarding question mark.
There we go. I thought it wasn't there then. There it is.
I'm gonna press next here, because I'm happy with the that commit that I wanna make. I only wanna push through that change.
So I'm gonna put make the commit from this dev sandbox to the feature branch, and I'll press next there.
It is worth bearing in mind that if you're kind of making commits with more changes to them, then it would be good either to use a metadata filter that kind of encompasses more metadata types. Remember, however, that any metadata that aren't included in your CI job filter, it won't show up in your pull request.
So as you can see, I've kind of made quite a simple change. There's, the problem analyzers haven't found anything. There's no warnings, no code quality improvements. So I'm just gonna keep on going and go to my pre deployment summary.
So I'm going to see I can see the custom object is no difference, but then the custom field is new, and that is the name of the commit that I make. Commit message is new custom field, and I'm then going to commit the changes.
So now that I've made the commit, I'm going to put create a pull request against the first static environment, and I'm gonna call it custom field. Very inventive.
So create a pull request, and I'll just refresh the page quickly.
So as you can see here, this new pull request has been opened against this integration box, and that is a PR that you can now see. The number here is three, and those are the number of PRs that are moving forwards, forwardly propagating into that integration environment.
You can also see one back propagation here, which I'll talk about a little bit later.
So in this list of PRs, there's a few things that you can look at.
So if I go into this pull request, there is merge and validation checks that have been carried out. The validation has been successful, but unfortunately, the pull request has merge conflicts, and I'll come back to that in a second.
Here is where you'll be able to see reviewers and other checks. So say you are using git, and you well, hopefully, you're using Git, and you have gated, checks so that, this PR can be moved forward. So you'll here's where you'll find those checks. So you have status checks here. And if you have any reviewers on each PR, then this is where you'll be able to see if they've been assigned.
This is the where the Jira issues will be found. So these are the, tickets that this PR is connected to. So SLA twenty DNIPS, and this is to do.
And then at the bottom here are files with changes. So these are any changes in this PR. So as you can see here, the changed item was the SLA serial number. And then finally, these are all the commits in each PR.
Now you saw at the top of the tab that there was a merge conflict that needs resolving. This is because, as I said before, they were going to there were changes that were made to the same XML tag in the same line. So what I'm gonna do is go ahead and resolve these conflicts.
So you can see for this particular merge conflict resolution, I'm able to use it, do it using our precision functionality.
So I'm able to select all on either side on either version of the of the merge conflict, or I can go ahead and pick and choose each individual one depending on what version of the, metadata I want to to be pushed forward through the environment.
I can then mark it as resolved here in the top right hand side, and then a commit would be made following that as well.
Now if you remember when I was talking about merge conflicts, there are some as well that Gearset is able to resolve automatically.
For example, when some of the changes within that same XML tag are conflicting but result in the same behavior in a Salesforce org. So in this scenario, you're able to see here that we say your version control system may display a merge conflict, which can be ignored.
If you're worried about that, you can head into your version control provider. For me, it's GitHub.
And you can see here that this it says that this branch has conflicts that must be resolved.
It's simply a kind of changing in ordering. So Gearset has dealt with this, and therefore, we say that no conflicts are needed to be resolved. And therefore, you can still promote this feature through your pipeline.
If we move on to the next environment, you'll see that sometimes things don't always go to plan. So for this new Apex class that I created, unfortunately, the validation failed.
So the tests that I, made sure happened on the new Apex class, they both failed, and so the validation failed, and I will no longer be able to push this PR through the environment.
Gear set allows you to view the details of the validation without having to leave Gear set, and you can see here that both tests failed because, I wasn't writing my Apex classes very well.
As we move through the pipeline, you can see that this, PR is ready to be promoted. So I'll just promote that change, and meanwhile, I'll talk about a few different things.
So the next thing I'm gonna talk about are release branches.
As you can see here, I have four PRs, open against my main branch ready to be moved into production.
If you work in a sprint workflow, say, biweekly, you're able to collate these PRs, all the PRs that you've worked on throughout this time, and move them into a release branch using this functionality here. So I'm gonna create this release branch here. I'm gonna call it October sprint, and I'm then gonna merge these, PRs into a release branch.
This may take a little bit of time, but what's happening is we're merging the PRs, closing them, and then opening a new pull request from the release branch to the target environment branch, which in this scenario is main.
So while this is happening, merge conflict checks and, other validations are also happening on the release branch much in the same way that, they happen on each step of the process as well.
Perfect timing. So I'll view release here.
As you can see, you're able to see the release. You're able to see if there are any Jira issues connected with each release. You're able to see each individual feature and also the changes that have been made in this whole release.
As I was talking about, the merge and validation checks are still happening, and you can, see that they're in progress. Any status checks that are needed and reviewers are the same, as well as any part in the pipeline.
A nice little trick about this as well is that you can schedule this release branch. So say at the end of two weeks, you know that you want to release in into production, you can schedule the deployment.
Once it's ready, it will then be automatically deployed into production.
If, say, however, that you are missing one of these PRs from the release branch, you can simply press it here and add it to the release branch here or create another release separately.
Okay.
So now that we've seen that, the final kind of part of the pipeline functionality that I wanted to mention, that I've already mentioned before, is the back propagation.
So this kind of happens twofold.
The first aspect of it is here, as you can see, this backwards PR into the, UAT environment. If I click on that, it is an urgent hotfix that I created in my hotfix environment.
I then pushed it to production, and then this then kicked off.
Oh, dry mouth again.
I merged it into the main branch, which then, kicked off the CI job to deploy into production.
And then because I created it in the hotfix branch, it did not go through the entire pipeline. So this back propagation is a way of, making sure all the environments and the environment branches are aligned as Gear set recognizes this, and so it creates this back propagation, which can then be pushed through each environment, making sure everything stays in line.
Secondly, there are the dev sandbox updates that I mentioned earlier.
This means that you can, you're able to synchronize your sandbox directly with promotions happening to your main branch without having to worry about work in progress and overwriting changes.
So you can see these right here.
You're able to select which update you want to do by clicking on each button here. Just bear in mind that these are done these are done in chronological order, but there is no danger of overwriting any work in progress. So you can either choose to update the dev sandbox all in one go, or you can update it feature by feature.
So as we're getting towards the end of this demo, there are a couple more things I'd like to show you. So firstly, this is the button here that I alluded to, earlier.
So this creates a sync PR from the main to all your upstream environments.
We recommend pressing this button after each release to production for a couple of reasons.
Firstly, it can be used to, sync any changes that aren't within each org, much like the backpropagation does, but instead, it works all in one go, and secondly, to avoid seeing extra merge commits in each PR.
So to explain this, I'll go back into the branching strategy here.
So as you can see here, merge merges four, six, and eight are all different merges. And therefore, due to a git behavior, each merge here creates a different merge commit. So even if they do bring in the same, metadata items through each branch, forget they are different commits.
Therefore, in order to sync these environment branches, you should press this environment sync button right here, which means that, so you should do that after every release to production. This will bring all the commits in main into all other branches without bringing any actual metadata as it already in the branch.
Instead, it aligns the history of the commits within the relative branches.
The final bit of functionality that I wanted to show you was the search function up here. So we've recently added this to the pipeline. If you've got lots of work going on, you're not sure where things are or how to find them, then this allows you to search the pipeline kind of as a whole, the different pull requests. So say I'm looking for feature test two, I'll find where that is, and it'll take me to that feature, that, PR very quickly.
So that's all for me, Maroof.
Are there any questions? Thanks for listening.
Sorry about the dry mouth.
Thank you very much, Charlie. Thank you for walking us through that.
We haven't actually had any questions pop up into the chat. So, folks, if you wanna ask us anything, we've still got some time, so feel free. But in the meantime, there are a couple of frequently asked questions that we felt, we will try to address today.
So I guess but one of one of the first questions that comes to mind, Antonio, do we need to back propagate if we're using, like, a shared sandbox, for example?
But not the pipeline that we have on screen now.
Not Even if we had only a dev sandbox on the left side, you will still need to back propagate changes coming from the outfix.
If there are there is not an outfix, environment there, in that case, probably, you will not need to update the sandbox after a release domain because the changes have come in from that sandbox.
Thank you, Antonio. You touched on hotfixes.
What if we have customers that don't have a hotfix environment?
You can download that.
It depends on what you mean.
How do you deal with urgent changes? So it might be that you need to make them, directly into production. Even if it's not recommended, they might be something that actually happened in real life. In that case, it is recommended to then commit those changes into a feature branch and enter the pipeline.
So for example, you can compare, the changes in production on UAT better. So it's not directly in production. Commit them to a feature branch, open up pull request against the environments in the pipeline, and enter like it was any other feature.
So so that the branches get updated as well.
Sure thing.
Charlie touched on some of the merge conflicts.
Would folks need to solve these conflicts in every step of their pipeline?
So, based on the, branching strategy where a pull request is open always from the original feature branch, it will mean that, the conflicts need to be resolved at every step.
But Kia said remember how you solve them the first time so that then when, the conflict is found again, like in this case, you will see what was the solution, the resolution that you picked in the previous step. So, it's yes and no. You still need to resolve at every step, but not remember, what you did in the previous step.
Sure. We just had a question come through in the chat, and that is, does back prop does backpropagating happen automatically, or do we have to perform this manually?
So the backpropagation PR is opened out automatically. Like, in this case, you see that there is a one on the right side of the UAT.
So that is a back propagation, and that needs to be merged manually.
So, back propagation is triggered automatically, but it needs to be merged in every single environment or all at once when you use the sync button.
Thank you very much, Antonio. Thank you, Charlie, for talking us through the pipelines within GESER.
I'm not seeing any more questions, so I'll start to bring today to a close.
But firstly, thank you, folks, all for joining wherever you are in the world. Thank you for joining us today.
That brings us to the end of episode number two. So we've we've still got one left.
We hope you found today and last week's session useful. As always, these sessions will be recorded, so we'll make this available to you alongside aside, alongside our library of various other enablement resources.
If you missed the beginning of this session, just a reminder that our product team is currently working on making it easier to set up pipelines in Gerson. Now we'd love to get your feedback on this. So you should you could expect an email from someone in the product team to, to reach out to you. And, if you'd like to speak to us, then please feel free to use the link that they share to book some time with.
And, finally, yeah, your input will really help make GIS set an easier tool to use for everyone.
As for moving forward in this, particular, series of webinars, Charlie, Antonio, and I will be back next week, where we are gonna be showing you how to maintain your Giasat pipeline.
We're also gonna answer some frequently asked questions about gear set pipelines. So if you have any questions specific to your pipeline or your setup, then we'd love to hear from you. So please do send in any specific questions ahead of time to success at gear set dot com, and we'll try our best to showcase it next week. In the meantime, any additional questions about pipelines, automation, or anything else in gearset, please feel free to contact Charlie or myself and the rest of your customer success team. Again, same email, success at gear set dot com, or drop us a message in the in app chat. But with that, thank you all for joining today, and we hope you enjoy the rest of your day.
Before I, shut off, I know there's a question being answered in the chat, so that should be there now.
Awesome. All good.
