Description
In this Gearset 360 session we’re taking a look at our automated CI/CD pipelines in Gearset. Part 1 provides some background context about this feature and why it’s useful for DevOps teams. Make sure to watch part 2 – the accompanying workshop that demonstrates how to set pipelines up.
Transcript
Okay. We're at one minute past six UK time.
So, yeah, let's get started. So thanks very much for coming along today.
Just to make sure you're up to speed with what's going on here. So this is the second of four of the Gear Set three sixty, series for this for this set. We had one a couple of weeks ago.
And, so this one is creating and managing CICD pipelines. In a couple of weeks' time, there is a backup restore session on, protecting and recovering Salesforce data. And then a couple of weeks after that, on May the second, a section on managing CPQ deployments.
So this is creating and managing CICD pipelines or how pipelines in Salesforce DevOps can unite teams, streamline deployments, and speed up delivery.
So quick introduction to me.
I'm Richard, one of the CFPMs at Gearset, and I've been at Gearset for, almost three years now.
And in my role, I've been in charge of the pipeline functionality basically since its inception. So with that, we've been working with hundreds of teams of different sizes to help make their day to day processes easier to manage.
So today, I wanna share with you what I've learned about how to help teams and especially larger teams be successful as they adopt CICD processes.
And we're gonna work with this to set up your own pipeline today as a t as for five across five teams over the next hour. So I'm delighted to be joined today by Matt, Masayo, Claudia, and Toby. So for the first part, while we're going through some of the slides here, drop any questions that you have on the way through in the chat, and then each of us are gonna be working with a group of you to set up your own pipeline a little bit later on today.
So here's the agenda for today. We'll start by quickly outlining some of the challenges that we've built Geartet pipeline to solve and outline some of the features that we built here to help teams, and then we'll dive into how to get it set up from a clean slate.
So first up, what challenges are we solving here?
So getting changes from development through production usually includes quite a lot of different steps. So you've got creating, committing, and testing the changes, running static code analysis, having people review and approve changes, and then pushing them from one environment to another eventually out towards production.
Now in best cases, those steps are enforced, but in other cases, they're only documented or in the worst case, they're only in the heads of the people who run the process itself.
So what is gearset pipelines, and what can it do to help make this process easier?
So at its core, we see pipelines as a visual way to externalize, organize, and automate the whole release process from the initial changes made in their sound boxes all the way through into production. So I'll quickly go through some of the benefits that it brings to teams that we're working today and some of the key features that you're gonna be getting your hands on in about five to ten minutes' time.
So this is a view of the pipeline's UI. It's recently changed. We've modernized some of the, the way that it looks, and it hits all the key parts of Salesforce DevOps that we need to manage today. So it's validating and merging changes, testing and deploy to environments in a really clear and coherent way.
And it's built on Gearset's long established continuous integration job framework. So changes are promoted between environments, and they're automatically deployed from the branch to the org as they push through. And changes are visible to users working in GIS and those working directly in, version control or in Versus code in exactly the same way. So you get the same benefit regardless of which of which place you're you're doing those changes.
And users can set up the environment and configuration that they need really, really easily. So adding an additional development environment can be done in seconds as we're gonna find out when, very quickly when we're setting this up ourselves.
So, here's the the branching model that we use in pipelines. So once once it's set up, here's how changes are gonna go through the main branch of the pipeline. So you'll be making changes in DevOps, push it into a feature branch, which we create from the master branch, and then you merge it into each of the target environments in turn. Finally, into production either directly or via a release branch as we show here.
So this provides separability of stories and the ability to promote different features independently through the pipeline at different rates.
And, so in this workshop, we're gonna be using, this mainline workflow, and we'll also be exploring the notion of longer term projects working alongside BAU.
So allowing you to, iterate on top of existing work before promoting that through as a project release.
So for the workshop part later, I'm noticing that this has been a very popular session. We're at about sixty odd people in the room now.
We've got so we've got Salesforce, for you representing a development environment, so one per team member, but we've got we've got five teams of nine. So, unfortunately, there will be a few few of you who need need to be observing for this session, but we'll try and make this as interactive as possible for you as well, as well as a shared UAT environment as well as a production environment and a project UAT environment for that long term project work that we were just talking about. We've also provided a repo, a git repo to use for this, which has got a, which will have a populated master branch only, and then it will be but then we'll be setting up all the branches and all the environments as we go, showing how easily we can do that.
So how does pipelines help you push changes through faster today?
So at its core, it encourages teams to develop in small units and promotes them through the pipeline quickly. And you can write stories through individually or you can provide them through in groups. Yes.
This allows teams to move from, an enforced biweekly process closer to on demand releases. But, of course, it is still a good fit for teams with print based release processes because we support both those, the creation of releases and pipelines as well as the use of project work that I was just talking about. And I will talk about that again a little bit later on.
In terms of clarity of process, we provide instant visibility of changes as they go through the system. It's really, really easy to see what's in progress at different stages of the process to be able to identify conflicts and resolve issues upfront.
And that's really shifting left as being able to do this early in the process, resolve any issues before it gets to a problem too too close to production. I see. And pipeline is designed to allow admins, developers, release managers to promote changes through those environments with real ease. Because if you're happier working in Versus Code or GitHub, you can use that to push changes. It'll work the same way as it does for users viewing it through our UI.
At the start of the process, when you're talking about your dev sandboxes and be able to get those changes into the pipeline, this is one of those, changes which has come in relatively recently, but which makes it so much easier for everybody to get started. We've made it easy for users to create that Git branch and push the changes to it. There's no in-depth knowledge of Git requires. You just select your user story, and then, we create the branch for you with the appropriate naming convention, and then you can push your changes to it and create your first PR on the pipeline really easily. And we'll go through how this works directly in the workshop.
Of course, with multiple changes in flight, it's quite possible, like, likely that we will encounter merge conflicts at times, and this may well happen in the, of course, this workshop itself.
But, of course, those merge conflicts aren't necessarily a bad thing, especially when the alternative is overwriting somebody else's changes without them knowing about it. And there are two ways that we deal with that in pipelines. So for most XML type changes that we that we're pushing where we need to merge multiple fields or elements, we merge using our semantic merge algorithm. So for things which aren't really merge conflicts, we can merge where git merge will fail.
So that's the situation that we have here. We mark something as this has passed on merge conflict check. In git, you see that there are conflicts which would typically come up on things like profiles, possibly things like layouts as well.
So it means that a lot of the a lot of the conflicts that Git finds, which aren't really conflicts, you just can breeze straight through them if you're using the pipelines UI.
But, of course, the changes which do contain true conflicts between development done by different users, we can't automatically resolve that conflict for you. We can't choose how to do that for you. So in this case, we'll mark it as not mergeable, allow you to view that conflict as it comes up. So here's an Apex plus conflict where you got two different versions of the same class being added, and then you can choose how to resolve it. You can even if it if it were applicable to choose both parts of it, you could choose that or even manually or choose to make manual edits to it in the case of Apex as well. All be done within the pipeline UI. You don't have to go out to get to do to be able to accomplish that.
Now Another challenge which a lot of users run into is keeping parallel environments up to date. So being able to back propagate changes into environments make it really easy to align those changes across environments. So being able as you those changes go into production, we'll create the back propagation change into your Hotfix environment. So it means that you can always keep your environment sales up to date very easily. We've got additional changes which are coming to make it even easier to update your dev sandboxes and make sure that they are always as close to up to date as possible as changes go through the pipeline.
When it comes to Jira integration, and we'll see that as we're as you're gonna be starting from user stories today, selecting a Jira story, pushing it through, you'll still we'll see that the information gets tracked on the tickets as you go through the as you go through the pipeline, and we also make it possible to update the tickets, update the status of tickets as they go through the pipeline. So here's you can change the status of the of the, change the status of the ticket as it as it goes through different environments, and any appropriate information could be logged out to the Jira ticket as you go.
Then at the end of the process, when it comes to creating releases, and promoting changes into production, pipelines allows that feature by feature promotion of all the creation of release branches against master to be able to deploy into production. So in that model, as you can see here, you you can, take you can create a release. You can add features to it over time and then validate it as a block. We'll be doing that in, we would do that live in the pipeline creation today.
So that makes sure that what you want to deploy is validated. It's ready to go. It takes the stress out out of the out of release day. And, of course, in this model as well, hot fixes, individual features can still be promoted through on demand where needed.
And then when it comes to projects, so here we've got in addition to the, long running branches for your integration UAT production, We've got a project branch here that allows you to have different streams to work at different cadences. And this is gonna be going into GA, should we at some point next week. So, in this under this model, you'd be able to create a branch off of master, be able to run a project branching from that sub branch, and then, iterate on top of that work until you got, the work which you need for the products complete and then push it back through the pipeline.
So that's a very high level overview of, some of the functionality that we're gonna be looking at in pipelines today.
And now without without any further ado, we're gonna be going straight into the workshop. So at this point, we're gonna be able to split out into five groups, five breakout rooms, and then we'll start the process getting set.
