Transcript
Didn't start now. Right?
Yeah. I mean, cheers.
Start the timer.
Okay.
Hi. Welcome, Jay.
Mostly would have most seen who I was this morning, this afternoon, just in case. I'm Johnny Harris. I work at Zurich as a Salesforce Release Supervisor.
Been at Zurich now for six five, six years. I've said earlier, worked through the journey, admin all the way up to the my role now.
Okay. So today, I'll be walking you through kind of how Zurich has implemented gear set pipelines. Now just to check, who has used gear set pipelines or doesn't know what it is at all? A few that have used it. Who hasn't used it?
Cool. That's up to date. Everyone seems to have used it.
So I'll walk you through what we've done this this year in reviewing back on our team. Again, like I mentioned earlier, continuous improvement of where what gaps do we have in our team and how we process currently.
We also then took those gaps and implemented and improved our pipelines.
Gonna talk for a bit for about long term pipelines that GES has released in the last six months or so.
It's a really cool tool to be able to integrate projects into a b a b pipeline and keep it easy to manage.
Some of the outcomes that we found in our team and then just covering off the, some DORA baselines that we started to gather at Zurich.
It's a good starting point of how to see see where we've got to and then where that we can improve from there.
So, yeah, I've said overview, identifying the potential gaps that you might have in your sales delivery compared to what we've we've seen, how we've implemented the Giza pipelines, the long term pipelines, and then also what you can achieve for those who.
Okay. So when reviewing some of the the delivery pipeline within our team at Zurich, you might find that some of these points resonate with you and and your team.
So we had, start of the year, no segregation of duty. So we had developers were taking their change from dev all the way through to production on their own.
Obviously, with that kind of model, it works for smaller teams, but you start to introduce some of that security issue.
And for us at Zurich, with regulatory bodies coming in, we need to take that away from the developers so no one can push through bad code on their own and not have any checks in place. We also had kind of inconsistent processes across the team. So we have five production orgs. Each org had its own slightly different process to get from development into production. So we want to try and align so that when the team shifts between the orgs, it's the same process across the board. So it's a smoother transition for the team.
We, we had different levels of quality and standards. So, you know, we had no impartial quality gate. Yes. We're doing peer reviews, but someone might peer review something at one level. The next person might look at it as a a slightly lower or higher level. So we had no impartial quality gates.
And also the the key one, sorry if I'm in the way, the project pipelines.
We had a place where it was difficult to merge lots of different projects into a BAU pipeline and also keep the projects themselves in line with each other.
And you could all face that issue where you have two or three different projects. One's going live first, and you get that back into the other one so they can test on the new code that's going towards production. So we had no easy way to get those to merge in. And also, it took a lot of time, especially when it comes to merge conflicts. When the whole project's going in, there's a bit of a big bang deployment, trying to merge that all back into the other projects caused issues.
So what I'm gonna do is just walk walk you through now what we've kind of implemented with pipelines in in a gear set and take you through that journey of what the devs kind of face now.
So starting on the far left hand side, the little little picture of the two people, we're now doing peer reviews right up front.
So the whole team, like I say, across all five orgs, they all have the same understanding of when a peer review will be done. So as soon as we open, so the little box there, if you haven't seen pipelines, you will have, is that peer peer review, the pull request being opened.
The devs there will now review each other's code, and it's a kind of expectation that they will align to our standards and challenge each other to try and improve the code. And that's as Torch just said earlier, is shifting left as far as we can on that, because the earlier you do it, the better the code, and you you get the improvements later on down the line.
We then come across the big blue line through the middle. So what we've now done is we've implemented a release line. So all the developers, what will happen is once they're happy with their code and it's in binning QA and they've done their unit testing, they then pass it over, at the moment, to myself to take forward into the other orgs. So that's our segregation of duty coming in place there.
And what we've done is utilized the security model in Gear Set to actually restrict anyone apart from myself and Matt, who kindly helps me when I'm on leave, to do deployments into the higher environment. So that's only access is then to us two and one other.
So no dev can just skip an org or just, oh, we're gonna deploy the pre prod quick just to see how it works and then forget that it's in them, cause issues. So within Gearset, only certain people can deploy up to the higher environments.
Then we've got and this runs through all of the pull requests that go through, the Gearset staff code analysis. So this is using currently the PMD rules to help us get that impartial review of our codes aligning to the industry standards.
So currently, we're working with our sort of security guidelines to try and improve our security vulnerabilities and stop any more going into our production environments.
And what this now does is any that fail the PMD rules will just fail the status check-in gear set to stop that code going any further. So it means we get a hard stop, and then it allows the developers to review that together and how to improve. And we have documentation on actually how do you fix that PND issue when it comes up.
The next one, is the the one down at the bottom. What we've now also got is within our source code repository, Bitbucket, we have set reviewers. So, again, that's followed on to the the security model we've got in Gearset. We've also now got it enforced in Bitbucket, so only certain people can approve PRs as they go through that pipeline. Again, past that release line, there's only three three people who can do that.
And, again, it stops that chance of someone. Maybe they think they've done a PR to QR going in, just approving it, hitting deploy, and then realizing, oh, actually, that was production. What do we do? So it's setting in all those kind of security mitigations.
We get to then into pre prod where we've got that consistent pipeline for all of our orgs, and this is just one of them just to be clear.
The business now know where they're expected to test. So if a business member might be talking to someone else from another part of business, they all have the same expectations of, actually, yeah, we've tested pre prod as well, rather than someone saying, oh, I get asked to test here. I test here. Why is that?
And in the final stage, as I go through, is the little box up here behind me.
We use the release feature in the pipelines tool to allow us to merge together multiple feature branches. So we take features all the way through until the end. We'll then merge it all into one release ready for our deployment. And what that allows me to do is validate that one package in one to go rather than five different feature branches all running at different times.
I can then see exactly what's gonna change from that whole package when it's gonna be deployed.
And then once it's deployed, it gives me a chance to look back and compare, does Salesforce match up to what we said was gonna change? Does the source code control match up? So our main branch, do they match up with what we said is gonna change?
And, also, does the, you know, the validation that comes out of GIS, does that all match up?
So these are some of the pipeline features that we've kind of implemented now, and we're really trying to utilize to the fullest extent to help us improve our, you know, code quality, our time to market with our changes, and give confidence to the business that what we're doing is aligning with best practice. And when it gets to production, we can be confident it's gonna work.
Now moving on to long term projects. So as I said, before we got long term projects, I did a fair bit of work. And I know Richard is doing another talk in, I think, Nextdoor.
I worked really closely with the gear set team, the product team, to work on a way that how do we introduce a way to get product projects into our BAA pipeline with the least resistance possible.
As before we had that kind of long term project, we had multiple sub pipelines. So what I mean by that is we have would have our main BAU pipeline. We then have another pipeline in gear set for one project and then another one for another project.
Now if you can imagine, when we got five production orgs, you start having two or three projects on each one. I'm suddenly man maintaining fifteen gear set pipelines.
So we need to get away from that and get it all in contained into one pipeline.
It caused me a lot of high maintenance and a lot of merge conflicts. So I said that taking the code out of project going forward is okay, but trying to get another project back into their code caused us or caused me a lot of work of trying to work out, okay, here are all the merge conflicts in Git, not even a nice UI to do it with. What's the right decision to make?
It also caused a bit of confusion with in our team to not understanding, well, why can't they receive a stand up? Why have we got a separate pipeline?
And also the final point there, that lack of security. So, again, matched up to the the Gears security model now, anyone could see any pipeline. So suddenly, if you had projects that might have been, of a certain level of what who can and can't view it, everyone could see all the pipelines. So it was difficult to manage and know who was access accessing what, looking at what changes we're going through. So it's a, say, just a difficult place to manage with lots of different pipelines, lots of different security going on, and all the merge conflicts.
However, Gearset has now, obviously, released their long term projects. And what you can see here is one of our other orgs with four different projects going alongside. So we've got our BAU track, the green line all the way along, and then we got the four gray boxes. Now these are four completely different projects that are running.
And what this now gives me the opportunity to is I can back propagate all of the BAU work into the projects. You see those little arrows going backwards.
That gives me the opportunity to know that when the projects are testing in their final environment, they've all got the most recent changes that we've done to production as early as possible. Again, it's shifting less. As soon as it hits staging, the projects are getting the BAU work.
I can also, when a project has a cut that's ready to go, back propagate that cut nice and easily into the other projects. So, again, all of the other projects are getting project work as it goes through.
What by doing that as early as possible, it's then now reducing the amount of merge conflicts that we're facing.
And, actually, I would touch wood if there was some. I haven't seen us have a merge conflict now for about three or four months, and that's with four projects running plus BAE running constantly.
So it's given us a lot of confidence that we know that the work we're doing isn't impacting each other projects when it gets to production.
And there's no confusion of, well, actually, I've changed this. Well, should you have changed this? Could BA you've changed it? Why is why is that confusion going on? So it's given us a lot more, confidence when with talking to the business as well when it gets goes live.
And also with now with the project long term project pipelines, it allows us to validate as early as possible with the project. So as soon as they finish that cut, like I said, it comes out. It's following our standards of what's following in BAU. So the projects aren't getting a special pre treatment to go straight to production. They're following the same suit of they've got a a line to us status code analysis.
They've got a line to our peer reviews, and they've also got to go through that release line and and come to me and have that segregation of duty that they all you know, the project will go, we think we're ready. We go through all the reviews, and then we'll make the agreement of when that project could go live.
Now on the next slide, it should have a very handy and great GIF that actually goes through and shows you how easy it is to spin up a project pipeline in Gear Set. So what this is doing is when it clicks around back to the start.
So when you look at your, pipeline, it's literally just a case of clicking the ad, click create project, give it a name, pick your branch where you're creating your feature branches from within the project, and then connecting it all up.
So Beanna do multiple projects that easy and spin it up within the pipeline tool, give the access to the team.
Again, it's saving me that maintenance cost of constantly doing it for all the projects. It allows me to then focus on how do we do other improvements, how do we improve the process server, and, again, like I said earlier, continuous improvement without doing the kind of mundane jobs to keep a project running.
I'll think let it play one more time. There it is.
Okay.
So as I said, we've gone through this journey over the last twelve months on looking back of what what where we were, what improvements, and what gaps we could resolve.
We've implemented all of that. And then what we've now started to find is by having, I said, like, a wow document and streamlined automated as well as CI jobs, a standardized delivery pipeline that's all built in GearSet, We're now starting to find a reduction in instance raised by the end users.
We found a reduction in the amount of downtime in production.
We've accelerated the realization of value, so that's that speed to market of that how long does it take for the change to be created at the very start, go all the way through the pipeline and into production.
We've got more frequent deployments now. We'll come onto this with the Dora metrics shortly, but we've now got to a point where we are running a weekly deployment.
Before, it was some orgs might have been biweekly, some were monthly.
All of our orgs now are deploying on the same day every week. So, again, it it gives that expectation to the business to know when that work is gonna come, when the changes are gonna be deployed. They know on a, you know, on a Thursday, the deployment will happen into production.
All the production orgs now have the same pipeline and gear set services. Saw that the BAU pipeline jump back. So this BAU pipeline that goes through the green boxes, they are the same for all five orgs.
That's given us the chance to facilitate smoother transitions in the Salesforce team between the orgs. So I I said quite a big team, five production orgs. It gives the opportunity for everyone just when they switch around, they know what the tool is. They know how the pipeline works without having to relearn every single time.
There's now better collaboration and coordination between our team, which is enhancing the productivity, again, because they all know how the tool works. When they talk to each other, they can pick out points to improve and actually all go, ah, we all have that issue. How do we address it?
We've also improved that way to work on the business. As I said, the business now knows when the production deployment's gonna happen, same across the business.
It's that easier way of talking to them. They know the expectations week in, week out.
We've also, like I said, achieved the PMD rules and static code analysis, which is now embedded into our pipeline.
That's given us the improvement in the code quality.
It's given us a reduction in vulnerabilities, compliance with regulatory standards. So being an insurance industry, we've got a lot of regulatory standards we need to align to. So having that now embed embedded gives us a chance to show the auditors what we are actually doing, and we're we're following that best practice industry standards.
And we're getting that higher code resilience. And I said we're not getting incidents and bugs for the end users.
We've got segregation of duty implemented with the release teams and myself at the moment doing all the approvals within Bitbucket.
That's given us the enhanced security and accountability for our team. We've got no single control over a critical process anymore that is between our team my team and the spread across the rest of the team.
And then we also, as I just mentioned, align now more to the regulatory requirements that we need to follow.
And then finally, just on this table, we've improved our testing processes as well. So not only have we improved our code quality, the way we work with our team, we're also improving our testing process. So that increases our reliability and performance of the software. You know, we've got higher customer satisfaction and also reliance in reduction, sorry, with the reliance of business testing.
So because we now as we build our pipeline, we're starting now to slowly implement some automating testing. The business won't have as much of a requirement to test.
I'll say just on the final final slide, by taking this year and having a standardized process across all of our orgs, it's now allowed me to start to track our DORA metrics.
So, again, as Jack mentioned earlier, DORA report is the one that comes from Google and the Google Cloud team.
And what it's given us a picture of at the moment is actually we might think we're in a certain position, but, actually, how does the how does Zurich compare to the insurance market? And this is the insurance benchmark. So the little lines you see in between is how the whole insurance industry is doing at the moment.
So I now know that, yes, we've done these improvements, but we've we've got a better way to go yet because, actually, our lead time is slightly below the benchmark average.
I know our deployment frequency, we could still get an improvement there. So there's gaps for me to now review over the next twelve, twenty four months of, yes, we've done improvements so far, but there's gotta be further things we can do to speed up within the Zurich team with our deployments.
And then the you can see the last two, the change failure rate and failed deployment recovery time, actually, we're above average. So it gives me and when I talk internally, there are confidence that what we're deploying is right.
It gives me confidence that when we're deploying, we're not breaking production constantly because because there's a fine balance with the DORA metrics, right, and how you deploy. You can either go right to the one end and deploy every hour, but you could drop off your quality to the bottom and keep breaking production. There's a fine balance and trade off that I think we're we're gonna find, like I said, next twenty four months where we can get to within Zurich and that balance point of what's the trade off. Because we can only go so far with it.
I think I'm a bit ahead of schedule, to be fair. So any questions?
Yep.
Yeah. So what we're what we're trying to look and do at the moment is with our testing tool is I'm now trying to introduce the, there's webhooks obviously built within the CI job in GearSet to get those automated test testing and the regression testing fired off when we deploy. So at the moment, it's just a schedule run. We regression test our entire org every evening.
I wanna bring that forward so that when we deploy into our QA environment, our test scripts run then, and then our team can get the results back sooner in that same working day. And And if it's broken or anything, we can fix it. So, again, it's that little bit of improvement of it helps us because we can fix the bugs quicker, but also the testing team hasn't got that reliance of they need to sit and wait till the code's got to them. We're hit we're hitting it. We're sending the test request off straight away.
Give them a chance to also, if they need to tweak any regression test scripts, to do that earlier.
Any questions?
Oh, great. I'm a little bit early, so it's early coffee for everyone, I think.
