Transcript
Alright. We can go ahead and get started and as people wander in, we can get going.
Thanks everybody for coming.
Jeremy Foster. I've I've also got a intro slide, so you'll see that again. But gonna talk about, scaling your Salesforce development.
Lawrence had a session and then I believe Amit had another session too. Very similar pieces, just different parts of the process. Lawrence introduced us to kind of the technological aspect of it. I think Amit talked to keeping it going once you've got that in place. And then my presentation will be how, pilot company is a company and our team, how we got to see our pipelines from manual deployments using Gear Set.
So just a quick run through. I'll do a little intro and then walk through why we scaled, how were we able to get there, the people involved, how Gear Set enabled us. And then if I get through it quick enough, we'll leave a little room for questions at the end.
So, I'll move out of the way. I do have a my LinkedIn up here in case anyone wants to add that. Feel free. I'd I like answering questions. I love talking about GearSet. So, just if you wanna add me, I've gotten plenty of questions on LinkedIn. I'd like to like to fill people in.
But I am the manager of Salesforce development for the pilot company.
We're a North American based company. We have roughly eight hundred truck stops across the continental United States and Canada. So we have the ply the Pilot brand and the Flying J brand. So if you're ever in the States and traveling along our interstates, you'll probably see a massive gas station that's red and yellow. That's us.
And then, we also have as a core team, there's a manager of, the administration side as well. But I have a slide. I'll I'll break that down later.
But that's myself.
So why would you scale your development process?
For us, it started with a question.
We've been using Gear Set since twenty nineteen.
We did a we did a review with GearSet to evaluate it against the change set process that we were using at the time. Very fortunately, I started with pilot in twenty nineteen, and I think only maybe three months of my tenure, I had to use change sets, and then we moved into gear set compare and deploy and never looked back.
From there, we had a lot brought to our team. Demand began to grow at the company, And my director at the time came to me with a question saying, this process isn't scalable. Can Gear Set do something for us?
What we were doing with Gear Set was comfortable and working, but we were hitting a point where even with compare and deploy packages, we were running into four to eight hours of work just from the complexity of what was being delivered and the number of teams working in our Salesforce environment. So we knew that long term, that was not gonna be sustainable. We needed to move into something that would help us, embrace that workload and that demand a lot better. So that's where I knew that Gear Set had CI jobs and pipelines, but we had never embraced them. And And so that was the start of our journey to see what we needed to do to get something scalable so that we could run efficiently with the number of teams and the amount of demand that was coming for Salesforce at our company.
So from there, how did we get to where we are today?
I like to use this example a lot. Credit Blizzard for this. I stole it from World of Warcraft. But, Fog of War came to mind once I figured out what we were doing because we stumbled initially. We built a lot of disparate CI jobs, and we're trying to piece everything together without a true understanding of what we needed to do to go from point a to point b. And so this felt very appropriate to me looking back because we had an idea of where we needed to go and we had some of it uncovered, but we didn't have the rest of the map unlocked. We didn't know exactly what we needed to do to make those connections work.
So I actually went to DevOps Dreaming in Chicago a few years back and got to sit in on one of Richard's classes on how to build out an example pipeline, and that's really where everything unlocked for me. I was able to take my developer background and traditional development practices and apply that to how Salesforce operates and figure out how to make the connection within Gearset to take our disparate CI jobs and actually create a functioning pipeline. I was able to take the understanding of repositories and change management and, merging and and everything I knew from being a developer and apply it to Salesforce. And instead of looking at it from an org to org, we shifted to a repository first mindset, and that enabled us to functioning pipeline. So we went from a lot of compare and deploy jobs and then disparate, like, click it and run it CI jobs to actually having a pipeline that would do the work for us.
So that was where we knew we were making a step in the right direction.
So initially, we started with manual deployments. We used compare and deploy. It was familiar.
We built extensive deployment trackers which were excel sheets that we had formatted so that we could maintain information on everything being delivered.
And it took a lot of time for a team member to build this, validate it, and then deploy it through the the different environments that we operated.
And then as the fog started to clear for us, we built individual CI jobs.
I was doing a lot of this and I thought that was continuous integration and realized, okay, I was still manually intervening on a lot of things.
We had separate validate only and deploy. So it was still me operating the pipeline. So we would go out and validate the process.
Once that ran, I would report back to the team, then we'd go set up a deployment for the actual release.
But we didn't know what we didn't know and didn't realize how disjointed it was until we had that session and realized how to connect the dots.
So then we got to the point where we actually had a pipeline. We could see the results working and knew that we needed to shift into a mode of training the team on how to use this process, get everyone to adopt it, and then expand it for not only our internal team, but their various implementation partners that we work with to support the workload for Salesforce at Pilot.
So just quickly, I'll go through some of these in case you're unfamiliar with what I've been rambling about for a bit.
This is compare and deploy, an example of comparing from an org and getting your results. We would build a package based on this. We would do our validation, often save our draft deployments, do a lot of manual back and forth, a lot of communication amongst all the stakeholders to make sure that everybody was on board.
And then from there, we shifted to the CI jobs. So I was in this screen a lot. I was running it, getting results, reporting that back, very often hoping to see that succeeded. Anytime there were issues, I would have to take that, export it, go to the team that built it, make sure we got everything fixed, attempted over again. And then once it was ready, I could run the separate deployment job, but it was still manual intervention on our part.
Eventually, we got to not quite this model, but today, we are very similar in this model. Initially, we only had a full copy sandbox and a production instance that we were running as a pipeline but that showed us that we were on the right track and we knew what we could expand upon from there. Today, we are in this model of dev boxes on the far left. We use a partial copy environment, a full copy sandbox, and then to production. And then we have hotfix environments as needed, to deploy any of those changes.
But it took a lot of learning, a lot of working with Gear Set, a lot of support from my team, and support from Gear Set success teams to get us to be able to use a very common practice but get to where we were comfortable with running through this process and get the whole team on board.
So with that, I mentioned briefly that we had started with a process that was two environments in a pipeline, and then now we're on the full environment pipeline.
Part of that was something that I learned a hard lesson on, so I like to share it when a when possible, but it was a sunk cost fallacy. We had an old repository that was built on the old metadata format for Salesforce.
And my nostalgia for that repository, because it was the first one that I'd worked with, really kept me wanting to keep it alive and limp it along. It had a lot of issues. There were a lot of problems with drift in the environments, a lot of problems understanding like what pieces were up to date, what pieces were out of date, how are we gonna get all this connected back up.
So at one point we had a, about a half day meeting with me and my engineer locked in a room and drawing on whiteboards and trying to figure out every possible combination of getting this thing to work correctly, get it in the new format, get everything caught up. And at one point, I just turned around and I was like, what if we scrap this? What if we make this repo an archive in case there's something in it that we forgot about and we can pull from it? But what if we start fresh? If we make a DX format repository, let's build a new pipeline on top of that. Let's go toward these best practices that Gear Set's been trying to help us get to and just just do that.
Admittedly, he was a little bit reserved and scared of like, well, that's a big jump. Should we do that? And then we spent maybe the last couple hours of our meeting really talking through what if we do this? Is this a good thing to do?
And just decided to make the leap.
So I put a little quote up there, just because it is how you've always done something doesn't mean it has to stay. And ultimately that's what we decided on. We archived the old repository. We can pull from it if needed.
Fortunately we've not had to do that in a while now. We shifted to a DX model, built our pipeline on top of that one instead, and instantly saw better results. We weren't fighting with drift anywhere as much. We were able to keep everything in sync with production and we really trusted what was out there instead of wondering did we miss something?
Are we gonna get caught by surprise down the road?
So I always like to to bring this up because it was a huge win for us to give up on holding on to something that we didn't really need to.
So Gearset provides this wonderful infographic on a DevOps journey, and I like to reference it to show where we started to where we are today.
We've gone to what I comfortably feel is an expert level just based on the characteristics and the benefits for it.
We all start as beginners. We went through our phase with it. We got to novice and practitioner. And today, I would feel that we're at an expert level simply because we have admins and developers that work inside of a CI workflow.
We use our GitHub repository as a source of truth. We do have continuous integration workload that goes through our environment. That way we're not sitting there for hours just waiting for the next thing to run simply because everything being delivered, we can validate everything, bundle it together, and give it a single release to production. We don't have to babysit things going over and over.
That benefits us by all of our changes are now in version control. So with the admins in there too, everything flows through this process.
Merge conflicts happen as they should within GitHub. We don't have to worry about things being overwritten within Salesforce as you're deploying org to org. We get automated deployment from all of our lower environments. So our stage gate is only production. This allows our contractors to deliver their work without us having to help them do that. And then because that's our stage gate, we get reliable releases to production that our team gets to control.
To get that can get to the expert level, you do have to bring the people with you.
This is a little bit outdated because we've hired some new people in the last couple weeks. But we do have the two divided teams. There's the admins and then the Salesforce dev team with, two QAs, two devs, and an engineer. We have two more devs.
We have two BAs on the admin as well. I say divided as far as responsibilities. We are a platform team, though. We all function as one team.
We just make sure that our responsibilities don't have to overlap. That gives us the ability to focus our team members without expecting the admins to know code or the developers have to write flows and validation rules, things like that. We do lean on each other, but it's not an expectation that they have to be experts in these.
So with this, pipeline adoption must be a team effort. You're gonna have a lot of mixed background and a mixed environment, or experiences.
Sorry. I skipped the other slide. But you have to bring people along with the challenge.
At a previous job, we were always told change is good. You go first. I always said, okay. Fortunately, the team was very much on board with that approach too. So we did shift our process.
We were able to learn a new way of working and then share that knowledge to everyone on the team. And then now we can share that knowledge to everyone that interacts with us. So it's not a sole person teaching it anymore. My team is comfortable with the process and they have taught it to our contractors and our new hires as they come on board.
Also would be remiss to say I know that's the, American version of the office. Probably should have switched it to the UK office, but it's where we're at. With that, as you teach people and you bring them along on your process, creating guardrails is a good, practice to involve.
We create best practice documentation internally. We create statements and ways of working internally.
We all agree on those as a team. We share that to anyone that's new to the team. Anytime we work with a new implementation partner, we also share that statement, ways of working or statement of work with them, get them to agree to it as well. And that just helps everybody work uniformly in the system that we've created, and that's reduced a lot of friction and a lot of issues that we had encountered previously.
These are really good practices when working with outside resources to help them work in the ways and processes that you are comfortable with and that you trust.
Talked a whole lot about how we did things.
Obviously, we wouldn't have been here without Gear Set. So Gearset provided the tools for us to get where we are today.
They allowed us to work step by step and involve the team to the process that we are now. They've been wonderful in providing success management to us and helping guide our knowledge and help us understand how we should work with the tools that they have.
So I always like to just give a shout out that, obviously, we wouldn't be doing this without them.
So and hopefully, I didn't blow through that too fast, but if there's some questions, I'll I'll take any of those. And if not, hit me up on LinkedIn.
Okay. Thanks.
