Description
Richard Owen (Sr. Product Manager, Gearset) and Jeb (Platforms Solutions Manager, Morgan & Morgan) dive into how Morgan & Morgan transformed their release process with Gearset Pipelines.
Learn more:
- Gearset Pipelines – End-to-end management of your Salesforce release pipeline
- View and manage your entire Salesforce DevOps pipeline
- Morgan & Morgan customer story
Related videos:
Transcript
Okay. Welcome everybody to accelerating releases, Morgan and Morgan's return on investment with pipelines.
So we'll start with the standard forward looking statement slide that you've seen many, many times this week.
Almost everything that you're gonna see today is in generally available where there's a couple of things which are in pilot, which we'll touch on right at the end of the talk.
But please do make all decisions on, generally available software.
They start off with some introductions. I'm Richard. I've been with Gearsat for just over two years now, and I'm the product manager for our pipeline functionality. So I've been working with hundreds of teams to help, improve and modernize their, release process.
And I'm delighted to be joined today by Jen. Hi. I'm Jeff Garrett, platform solutions manager at Morgan and Morgan. I've worked with Morgan and Morgan for a little over four years now, and I'm responsible for all the admins in our environment and our DevOps process that we use to move changes through Salesforce.
Cool.
So here's what we're going to be talking about today. We'll start off with a quick overview as to why developing a robust DevOps process on Salesforce can be a challenge. We'll then, go into what we've built help meet their challenges head on. And that, of course, is gearsight pipelines. And then we'll go go into a, a real life case, real world case study with Jeb going through the process before they adopted user and pipelines, what did the PSTN implementation look like, and what was the return on investment that they have, achieved? Since adoption.
So first off, why is Salesforce DevOps challenging for a bunch of teams today? So we see there being three main aspects to this. The broad technical diversity of Salesforce teams today.
The technological barriers that there are on Salesforce platform, kind of quirks of the platform, and the cultural shifts, which teams need to adapt to be able to be successful and release faster.
So first off, that technical diversity question. So any DevOps process, a release process needs to be inclusive for all members of your team.
And team team members need to have visibility over the process. And this can be real, a real challenge for a lot of team on Salesforce because Salesforce teams are really technically diverse. You've got a whole range of different roles from, from admins on one side, the clicks on one coach side to pro code developers on the other. And then you've got, business analyst, release managers, all sorts of different roles who need to engage with the same process in slightly different ways.
And if you've got users in users in the process who aren't following those best practices, so they're may they may be making changes directly in production, they may be doing org to org deploy instead of using version control, or they may not be back propagating changes properly into their sandboxes. This creates a bottleneck, and it slows you down. And at the end of the day, your releases are only ever gonna be as fast as that slowest part of your process. So what teams really need is a clear release process. They need good visibility and they need body to be on the same page.
On the technological side, Salesforce platform is brilliant as a user user centric platform, but it wasn't necessarily built for collaboration between different team members making changes to that platform. So particularly if you're making changes, you can easily lose visibility of what your teammates are up to. You could easily overwrite other users' changes, and that's particularly common when it comes to cross cutting objects. Things like profiles and layouts, all of those things which you're going to be hitting as soon as you're making any kind of declarative change. And this also means that merge conflicts can come up a lot.
Then stack on top of that, like dependencies of the, of different metadata that you're trying to deploy quirks to the API, which mean that some objects can't be deployed as easily as others, And then it becomes pretty clear that generic tooling or general tooling won't really cut it. You need to have something which is Salesforce aware, something that's a specialized process to be able to be to to really be successful.
And then on the cultural side, so DevOps processes. So by that, I'm talking about shift left development, being able to test early in catch mistakes early and be able to spread responsibility to cross the team. That's been around for coming up it's coming up on two decades now.
But it's it's a bit newer to the Salesforce ecosystem.
And teams who are doing this in regular development and now in Salesforce development, they when they adopt these processes, they're just more successful because they break down silos, they improve coordination, they improve they improve communication, and they, they're able to release faster and more reliably. And that's the goal of what we're trying to do here. So what we're looking for is a process by which we can go from kind of structure where you've got everybody working in their own individual, environments, their own sandboxes, and then they just have chucked the work over the fence for the next person. You wanna move it to something which is much more coordinated where you've got everybody working together. Everybody's got visibility of each other's changes as to where they've got to. And then they're able to communicate better as well.
So what have we built to help address this problem?
And that is, of course, PSIP pipelines. So we see it as a visual way to externalize, organize, and automate your entire release process. All the way from those first changes that you're making in your sandboxes through into production.
And this is an overview, a very high level overview of what it looks So it covers all of the key parts of the dev ops process that we manage that we need to manage today from the initial commits that you're making into your environment. Testing and validation, static code analysis, then all the way through each environment all the way through into production.
One key aspect of it, is that it has to be accessible to your whole team. So everybody's on the same page. Everybody has a good enough knowledge of where their changes are, and Git is no longer a barrier to entry. Knowledge a version control, you don't need it to be successful with pipelines.
And it sits on your existing systems. So we can work with your own version control, your own repo right from day one.
Now, we've been working with over two hundred teams now ranging from teams of two to three up to teams of nearly a hundred all on this framework. And Morgan and Morgan is one of these teams who has been successful recently. So, Jeff, can you give us an overview as to what your process was like before you started working with Kiasat? Absolutely.
So at Morgan to Morgan, we want to continue to be a leader in legal technology. And a big part of this is to drive value for our clients.
So it takes a lot of effort to get your DevOps process where you want it to be. And when we adopted Salesforce, part of that part of our strategy was the ability to be able to make changes quickly so we could react to changes in the legal landscape. When I first started, we had a really basic process. It's something that you guys may be very familiar with.
We're listing out all of our items on Google sheets And then we were going through and making change sets and pushing them up. It was a very time consuming process. We had all of our admins and developers. We're going through adding each item one by one, and our release manager was going in grabbing them, adding them to the change set.
Even using third party browser plug in tools, it didn't really help. I mean, it was still an arduous process to do. And the result of that is we only had one sandbox that was pushing directly into production that was for UAT, QA, everything.
As time went on, we realized that we needed to make a change. And the team wanted to continue to grow. So as the team grew, we got more admins, more developers. Our QA process was overhauled, and we ended up getting a version control system.
But there were a few things that we didn't account for that ultimately limited our success. It was our experience with the metadata API.
It was our admins not fully understanding git. And in as a result, we had a process that although it was better for them what we were doing before, was not really conducive to what the team wanted to do. We had unhappy admins, unhappy developers, and we weren't meeting the goals of the business.
And that brought you to the point where you started working with gear set. So whenever we start working with any new team, we, look at where their situation is, where they're at now, and understand what what's the next step? What makes sense? Because it's never a one size fits all process. And to do this, we we generally do this through our dev ops maturity room. So going from chain sets on the left to a fully fledged dev ops process with backup and restore on the right.
So where would you say that you were on the spectrum start of the process. And how did your, POC and implementation, like, get that go? Absolutely. So, after about a year of using the system that we were in, it became time to renew or make a change. And we had to make a decision.
What we had done before is we were really at like level one here. We were at a very, very, very basic process. But we had put in a process that was really kinda like level four. We tried to jump too far ahead too quickly. And that was really a part of the problem that we were having.
As we kept going, we realized that we needed to make a change. So we only had thirty days to do this. Literally, thirty days from the time that we were beginning our search to the time that we had to actually implement a new solution. So we ended up going out, collecting the requirements, interviewing the admins, making a few tweaks, And after a little while, we had everything we needed to begin our search.
We talked to four different companies, and each team had or each company had a team of people calls. You had a sales manager. You had a sales engineer. And they were showing us how, you know, they could adapt their process to what we were doing.
But it wasn't really something that we needed. It wasn't going to work for us. We we had tried this before. We had tried to run.
We had tried to, you know, run before we could walk. But gear set was a little different. They had one person on the call. His name was Matt Jackson, and he was an expert in all things DevOps.
He was able to show us branching strategies. He was able to explain the benefits of the tools. He was able to show us at perfect CICD process. But like I said, we weren't ready for a perfect CICD and that's what was so beneficial about gear set.
If we wanted to start off really basic and just do straight org to org deployments, we could just utilize their comparison tools. If we wanted to take it a step further, we can do an org first process. Use get to back up our changes. If we wanted to go full on CICD, change management, everything.
We had we could do that too. We we had the tools at our disposal to build our process the way we wanted to. And this was really key to our success.
So what did our end result end up looking like? Well, We were looking at what the key factors were that were going to make us successful. The first one was modularizing our deployment process. We wanted to make sure that any one of our changes that we're pushing out were cohesive units of work that we could move because we never know what's going to happen on a release.
You could have an item in the release that the business determines, hey, we're not ready for that. You need to pull it out. You could have had an item come in last second that needs to go in right now. Absolutely have to react to the business needs.
This is really important is to modularize your changes to go up. The next thing is reducing the number they're reducing the time we have making comparisons. We needed to have a tool where we could make a comparison once and have it be reliable that we knew that same change is going to go up into each environment. This is really important for gathering, for garnering buy in from the team.
And the last piece, garner buying from the team, was never forget the people that are using this process. They're the devs and the admins. They're in this day in, day out. It doesn't matter if you have the best version control system in the world.
If it is not conducive to what your admins and what your developers wanna do, it's not going to work. And this is a big key on developing good DevOps process. Cool. So which so what branching strategy did you end up with as a result of this process?
So, this is the branching strategy that we kind of ended up with. This was our first first iteration of it. So we knew that we wanted to get involved with git, but we couldn't allow a process that was going to give more problems than solutions. So we went with an org first model.
This was something to kind of ease our team into so that they started getting that experience, started to get that development speed. I mean, not everyone on your team is going to be a rock star right out of the gates. And you need to have a process that's investing in those people so that they stick around and they continue to grow with your team. So what we were doing is basically backing up the changes from each of our environments, putting them into branches, and then the last step was a straight org to org deployment because the team felt comfortable making an org to our deployment at that very end.
This enabled us to do a few things, include create a branching strategy that allowed us to start using branches to, again, modularize those changes and push them up. This is our team getting more involved. The admin started getting more, started to get more experience with it. The end result of this was it was a few more clicks than what we were doing before, but the overall time spent on moving changes up was reduced dramatically.
Our deployment process on the last step wasn't perfect, but it was much better than it was before. And at the end, we were able to actually adapt to the changes the business wanted But our story doesn't end there. You gotta keep sharpening that edge. Right?
You gotta keep making your process better. So then, one day, Gearsaid approached us about doing pipelines, and pipelines had a few big advantages that we didn't see before. Number one, it was a clear visual representation of where all of our changes were in the environment. So for me as a DevOps manager, I mean, that was really good.
I could see, Hey, here are all the tickets waiting to go to UAT, here are all the tickets waiting to go to It also had prevalidations. So I could see that the validation, whether or not that ticket validated, whether or not there was a merge conflict. It was really good. Another big thing that pipelines allowed us to do was had an easy CI job or CI sync in between the Oregon and the branches.
This was important for our release because again, they weren't experts in Git yet, and we needed to make sure that they were able to grow. It was very easy, very configurable, made their lives a lot easier because I wanted them to own the entire process from beginning to end.
So we sat down, reached out to Gear said about implementing this. And they set us up with one of their engineers Toby. And when we did, we realized that we didn't need to have a staging or going into production like we had before. This was one less step that the admins had to go to get into a org, air to get into production.
And as a result, sped up our deployment process We were starting to become more reactive. We were starting to be able to make changes that the business wanted. It was really important to our success. Cool.
That's fun. That sounds absolutely fantastic.
And, with that, so one of the biggest changes that you've seen in the products is the functionality which has helped you and become more efficient over time. Absolutely. I think one of the biggest things is the ability to be able to do releases.
So creating releases and gear sets very easy. As the changes go up, we're able to start doing pull requests now. Right? And again, another thing that admins aren't experienced with but now they're able to do pull requests, something that usually the devs are doing.
And when you create those pull requests, you get a nice list here of all the different items that need to go up. From the release manager's perspective, it's super simple. They literally just go in, check the boxes on all the changes they want to go up, click create promotion, it goes ahead and brings them into a brings them together. They name it.
And from there, gear set takes it. It begins doing a merge on them. And, you know, or it begins to merge those together. And as it does, it gives you a clear, insight into whether or not that package is going to make it up into production.
Prevalidates a pre or it doesn't merge. It really takes care of everything. It really couldn't be easier on our release managers. Like, it's very, very, very simple.
That's pretty cool.
And we were talking earlier on about about merge conflicts and how teams, I mean, it's easy to step on each other's toes through this process. However, we found that experience changing over time. Absolutely. So merge merging is something that as your team grows, it's just merge conflicts are gonna happen.
It's you gotta have a lot of people. They're gonna be trying change the same thing. You're gonna have multiple PMs coming at you from any either direction. So having merge conflicts, or being able to do a merge conflict UI is is really important.
Again, admins aren't used to being inside of git. They're not used to doing a merge. So you wanna create an interface for them to do it. And that's the thing.
Not only is this really nice because it enables you to select changes from each side. So you don't just have to pick a winner or a loser, which is kind of like what we were doing before. We're able to actually combine them together, or you could just pick winter and lose it. I mean, it's however you wanna do it.
But another thing that gear set does, and I think this is the most important thing is for those of you who have experienced this before, the metadata API does not return things in a way that is conducive to what git wants to see. So git will tell you there's a conflict when there actually isn't a conflict, or it looks different in git, but the end result in Salesforce would be end up being the same. And gear set is able to handle these. So you only get merges on things that will actually be different in the environment.
And this is really honestly, we couldn't have the team as large as we are today without a tool like this.
So at the end of the day, what's been the impact of these changes? How have you seen this impacting you kind of quantitatively, what changes have we seen? Yeah. So let's take a look at some numbers.
So this is showing you kind of back in nineteen. So this is when we're using change sets. And as you can see, we're getting, you know, less than forty tickets up a month, roughly. So we go on into twenty twenty after COVID.
It's a terrible time.
And you can see that we have a huge spike here in August. That was actually our first attempt at doing a version control process. And this, I think, shows you just from going to change sets to getting anything in place, you're gonna have a boost. I think this is really important to know.
If we go into twenty twenty one, you can see we kind of level out doing roughly about the same same amount changes in May we moved over to gear set. Twenty twenty two. We're doing about the same. We're actually up about six percent over the previous year in twenty twenty three.
Then we see another spike in, sorry, twenty twenty two. Then we see another spike in twenty twenty three. And this is where we had switched into pipe ones. Since we have switched into pipe one, We have roughly the same size team that we did in twenty twenty two, and we're up twenty nine percent on the amount of changes that we're able to get out per month.
It's it's a lot of work. But let's look at another number. Let's look at the deployment frequency. Right? This is based off the door metrics, which you get if you guys aren't familiar with it, it's a great way to measure your your success.
But as you can see here, we're averaging about ten changes per per month. And then we again go in there you can see in August, our our, boosting the in, change control. And then going into twenty twenty two, we start twenty twenty one. We're going up twenty twenty two.
Level out. We're actually a little bit lower, but we're about the same that we were before. And then twenty twenty three, again, you can see a bump here in April from when we went into pipelines. We were up thirty five percent on the amount of releases that we were able to get out each month.
And this is important to the business. This means that we're delivering on more projects, we're able to expand the amount of work that the team is able to do. Also note that again, this is amount this is about the same size team that we had in twenty twenty two, but we're actually getting thirty five percent more changes being pushed out. And then let's look at this last metric.
So this one's a little more modest. But this one's showing, you know, what is our lead time on tickets. So six point three five days before pipeline, six point one four. So just to note, this is not accounting for weekends.
Stuff. This is literally just the amount of time that it takes to get a change out. It's important though is that our team continue to grow, but we're actually able to get changes out faster, which is crazy and to to just kinda show you, like, you know, part of it, I mean, we got nineteen tickets out same day for our business last month. So things are really moving rapidly for us.
If you look at, you know, kind of a summary of everything, it's important to note that, you know, our team grew three times the size from when we were beginning to use change sets to when we got into pipelines. Yet we've had a five time increase in the amount of changes that we're able to push through. Twenty nine percent up on the amount of stuff or on the amount of changes we push through. We're thirty five percent up on the amount of times we actually push, and we have slightly better, lead time than we had before.
This is honestly without pipelines, we wouldn't be able to be where we are today. And honestly, I'm very excited for the future. Yeah. Same here.
It's been brilliant what we've managed to achieve already and looking forward to looking forward to the future. So if you want to know more about this, then either come and find us afterwards or any of the wonderful people in yellow polos around the room. And our booth is over at fifty nine, the other side of the customer expo. Thanks very much for coming along, and have a great recipe for us.
Thank you.
