Scaling Salesforce delivery with CI/CD

Share with

Description

In this DevOps Launchpad webinar, Jeremy Foster (Salesforce Development Manager at Pilot Company) shares how his team scaled their Salesforce delivery using CI/CD. You’ll hear firsthand how DevOps Launchpad helped shape his understanding of CI/CD, how he tackled challenges during Pilot’s DevOps transformation, and the real-world impact of adopting CI/CD pipelines.

Learn more with these resources:

Transcript

So without further ado, I'm very excited to introduce you to today's speaker, Jeremy Foster, manager of Salesforce development, a pilot company. So if everyone's ready to get started, Jeremy, I shall hand over to you.

Cool. Thank you.

Hello, everybody. Welcome to scaling Salesforce delivery with CICD.

I'm gonna walk through some real world advice from previous experiences we've gone through in implementing a CICD pipeline process here at the pilot company.

As Amy mentioned, my name is Jeremy Foster. I am manager of Salesforce development here for pilot.

I actually share management of the team with a co manager over the admins. I am responsible for the devs, engineers, and QA team members, also over the customization side of our application, while the admins and business analysts, that make up the other half of the team are over the setup and configuration for our system.

As Amy mentioned, I am going to try to go through this with some haste just to give us plenty of time at the end for, questions and feedback.

So please feel free to prep any questions for that, and, hopefully, we'll have time to go through everything that everyone has.

So CICD and Salesforce, why do you need it? What does it do for your system?

When coming up with some of the content for this presentation, I thought back on how I got to where I am today with Gearset, with our CI pipeline, with the tools that we use, my experience with Salesforce.

I've been in the Salesforce ecosystem for about nine years now coming up close to a decade of using the tool.

But my background is as a developer from school and early career. I worked in a variety of different applications and systems, all of them using practices we're all familiar with around Git and version control systems, version control software.

And when I was thinking through this, I had actually, found a relic of a past job here in my office, at the house and thought it would be a a great example to to talk about my experience moving from systems very common to version control into the Salesforce ecosystem.

So at a previous job early into that career, I actually worked on an application supporting a team using COBOL at the time. And we built, an application with that code, and they had actually home brewed their own version control software for it. And, I still have a relic of that. I I don't know if you guys can see it easily on the camera, but, three and a half inch floppy disk.

It was the only time I've encountered a physical repository system. So we actually checked out our code using a three and a half inch floppy, took it to our personal machine, wrote our feature, committed our code, onto that floppy. So, physically, I am holding an old commit in my hands.

Then we would take that. We would print out a document. We would write everything in that feature and commit, put it into a manila folder. And then at that time, we actually put it into a, filing cabinet in my boss's office at that point.

So for a while, there was a file cabinet there that had a physical repository, of all the work that we were doing on that system. Fortunately, they they moved on to a better system, and and all of that is is now moot. That's why they they don't need any of the the repo stuff. But all of that to illustrate that even then, on a software that wasn't as modern as, say, Salesforce, we had a version control system because the practice gave us that safety net.

It gave us those tools to support the work that we were doing and have a way to fall back to a previous version or isolate some work that we were doing within a commit and a feature.

It gave us these tried and true practices for development.

And then I moved into Salesforce and was very shocked that in that system, there wasn't really a native version control built in or they weren't making use of version control within GitHub or Bitbucket tools like that. You really had to rely on trying to build that structure within your orgs. But even then, as we all know, your sandbox orgs aren't as robust as version control. You could accidentally delete an org, and it has content in it that you needed. And you don't know that and you've lost it. You could easily refresh an org and forget that there was something in there you forgot to move through, and and it's now lost as well. So you need those tried and true practices in a modern tool whenever you're developing or creating configurations even as an admin.

With that, I think this would be a good place to call out too that, DevOps Launchpad that Gear Set provides has a really good module on version control software and and how to use that, the the language that is native to that type of tool. It'll help you get caught up and informed on it if you're unfamiliar with it. It'll also be a good refresher if you've not used these tools in a while, but, it's a great resource to go learn some of that.

With that, shifting into how we leverage these DevOps resources and what we learned along the way, trying to implement version control.

It was definitely a challenge, to shift from Salesforce out of the box change sets to having a full pipeline.

Often I hear change is good. You go first. So we did.

Personally, I've never been one to back down from challenges in in my career, so I like seeing what is out there, seeing what's different, learning new processes.

So we had to, start learning where we could. We developed, in, gearset, we shifted over to manual compare and deploy at the time. This was back in twenty nineteen. We shifted off of change sets and very thankfully never had to look back on those other than training someone and and telling them why we were using gear set for manual comparison instead of the change sets that were there.

We, at the time, were a team of four to five individuals.

We learned the process. At at that point, it was just a couple of us, and then we were able to teach others. The others also learned manual comparisons very easily. It was definitely a much more robust version of change sets, so that was it was an easier adjustment to move into those. And then along the way, we started moving into, a more robust process. We we temporarily implemented individual CI jobs to run.

I incorrectly thought that was our step into the pipeline process at the time. And as I'll explain here in a little bit, that was an eye opening experience to make that connection of how these disconnected CI jobs would turn into the pipeline that we have today. But that was all learning along the way and and being willing to learn from others, learn from tools like Launchpad, learn from people at DevOps streaming, and figure out how to connect the dots of things I have learned in my past to get us to the point where we can use that automation today. With all of that, I do think it's important to call out that everybody is going to have different levels of comfort and experience with the tools and the processes that you're wanting to implement.

That can be from having no experience whatsoever and being very uncomfortable with it to maybe having no experience but being comfortable with change or, having some experience but being uncomfortable with shifting how their work happens today. So just with all of those, you'll just need to evaluate where your team members are and get people adjusted to learning some of this process and teaching others. Sometimes it helps to learn from a peer instead of a leader, but those are things that in your team, you'll be able to figure out and help pull everyone forward toward the, the common goal.

So our journey, as I've mentioned, took us from manual deployments in twenty nineteen to our first iteration of the pipeline, a couple years ago.

How we got there, the manual compare and deploy was was really easy.

Any of you who have experienced change sets, I I don't think you'll disagree that they're not the greatest. It is difficult. You have to clone and and reiterate a lot of things, especially if you miss anything. There's a lot of delay.

It is a outdated process, and something as simple as manual compare and deploy was such a leap for us in being able to run faster and do our deployments better.

Along the way, though, that was supporting a single team, as I've mentioned, of about five people. Salesforce was utilized, but not to the extent that we are today. So as our company demand grew for Salesforce and the projects and teams that we supported grew, the scalability of manually comparing and deploying for all of your releases was starting to get unmanageable.

We were getting to a point where we were handling four to eight hours to build a deployment package so that we could hopefully, either that afternoon or the next day, do the deployment.

We kept track of all of our work in an Excel sheet. We called it the deployment tracker, but we used that to build out a change package, which was containing everything prepped for release, one day a week at that time just because of the the extent that we were building things out. That was what we could manage. So everything got built into a release package, went through its validations, and and all those stages to get prepped to go to production.

It was just while it was comfortable and it was something we were practiced at doing, it was getting slower and slower. And we knew that that demand was just going to keep growing. And, fortunately, this was a question that my director at the time came to us with, and he just called out that this process isn't scalable. Can Gear Set do something additional for us? Like, we've seen the improvements that we got with our compare and deploy. Is there, like, a next step for us?

We, we knew that there were CI jobs. We knew that there was the potential for a pipeline. I was trying to connect some of my past experience to what we could potentially do with the tool, and this was all a learning process for us. So, nothing was sacred in what we were doing, so it was a good idea to question everything. And we realized that the the comfort we had with manual compare and deploy was gonna slowly kill us if we couldn't catch up with the scalability that we needed.

And that's where it was good to have tools like DevOps Launchpad to start learning some of that. And then for me, a really big boon was going to, DevOps streaming and getting to sit in a session with the project team and learn how to implement a pipeline from scratch there. And it helped me connect dots or as I've called it in, other sessions, cleared the fog of war. Like, I I knew kind of where I was, and I knew a bit of where I wanted it to go from other systems, from custom code and version control tools there, but I didn't know how to make Salesforce and and that other knowledge connect.

So we took a stab at it and started implementing CICD.

Gear set does provide this handy, chart to kinda put where you are. Obviously, we had started with the beginner back in twenty nineteen.

We moved into just using our manual compare and deploy.

We worked through that for a while. We slowly got to a point where we were working through with the CI jobs and occasionally getting some of the, availability out of not having to manually deploy with that, but it was still not fully connected. It wasn't providing the kind of speed and scale that we were looking for.

And then, fortunately, today, I feel like we've at least gotten to the expert level. I feel there is always room for growth, tools like code reviews from Gear Set, monitoring and observability, trying to add some of that, improving automation around our testing and automation around our practices fully, that will help us advance for from where we even are today.

But how we got to even the expert level, we went from the comfort I mentioned around our compare and deploy, being able to find all the items, save a draft deployment as needed, and validate that and have it ready and and use that as an intermediary to some disconnected CI jobs that I mistakenly thought was a pipeline for us until I I figured out better.

These were at least helping automate some of this. We were still having to build the work manually and then push it to the the CI job, and it would run the validation for us. But then we'd every stage, we would have to manually go in and release that to the environment. It wasn't automated. It was helping.

Looking back, I would consider it more of a stopgap at this point, but it wasn't where we wanted to be and where we needed to be. But it did give us that bridge between what we were doing with the manual steps to where we wanted to get to with an automated pipeline.

Through that, through a lot of learning, a lot of trial and error, error and time, we eventually got to a pipeline. This is an example. I pulled it from GearSet. Ours looks similar to it, but I think everybody's will be a little different just based on how your dev environments are set up and how you wanna follow that flow. But, essentially, we have all of our dev environments on the left hand of our pipeline. We flow everything through a partial copy and a full copy into production.

We handle hot fixes as we need, but the pipeline itself allows the flow of all of our work to be automated through the partial copy and the full copy. We're able to use stages in the, repo around, like, branch protections to enforce reviews, to make sure that everything's getting evaluated, that we, allow the team members to self serve all the way up to UAT where there isn't enforced that a review happens. But even then, they can self deliver that to UA to, the full copy labeled UAT here.

And then it'll stage it against production. And because of our internal change management process at our company, we still have that as a manual step there, but that allows us to plan those releases, get everything validated, scanned, and approved beforehand, and just have it ready. That way, as we do our releases throughout the week, we can have all of those staged and ready to go. And then it's just a release process to step in, bundle everything that's ready to go on the release date, and and push it through to production.

From developing the pipeline, just some learnings first, some of our impacts, and then then I'll give a little breakdown of the results.

One of the things I'd really like to call out is some some cost fallacy that we ran into when building this.

Some of the things that we had were just things that we'd always had here, since I started in twenty nineteen. It was just the way it was. We had a repo to back up our code, but we didn't use it at the time when we were doing the manual comparisons.

We eventually incorporated that repos. We built out CI jobs and built out the first pipeline that we had. Unfortunately, that repo was built in the metadata API structure.

It became really cumbersome to keep everything in sync, and we were dealing with a lot of drift.

So at that time, myself and my engineer, we met together and and put our heads together on, like, how can we fix this?

We were concerned about keeping that old repo alive and how would we clean it all up and just the growing mountain to, climb to get that repository fixed. And, that's where I kinda thought of the sunk cost fallacy. Like, this was nostalgic. It was the the way we did something, and we were really reluctant to abandon that process and and the way we were doing it just because that's how we had always done it.

And it felt safe to keep it there even with all the problems that we had. And I threw out what felt like a crazy idea at the time of, well, what if we just spin up a new repo? We'll make it in the Salesforce DX format. We'll match everything to our production org and use that since, obviously, it was still the source of truth.

We can keep the other repo around as an archive to pull from in case anything was missed, and we can do comparisons that way.

And we we shifted. So it was a key decision that we were able to make at that time. And and looking back, while it was scary in the moment, it has definitely saved us time and provided a lot of stability for the next iteration of the pipeline that we were able to build from clearing a lot of those hurdles around the metadata version that we were working with previously.

So all of those learnings, all of that process got us to this enterprise scale and support that we have today.

Just at a very high level, we're supporting four different project teams in our enterprise instance.

We have gone through projects where we've also worked with three different implementation partners who are able to take advantage of, our repository in the pipeline, using that interface to deploy their work as well.

Internally, on the platform team that I co manage, we have sixteen team members between admins, devs, and analysts.

I have a little breakdown on the side. We're supporting five admins, two business analysts, five developers, an engineer, two QA. And then recently, we even supported an intern while she was here during our internship program, and she was able to learn the DevOps process we use, learn our CI pipeline, take advantage of tools like Trailhead and and DevOps Launchpad to familiarize herself with some of those features and some of the verbiage around that, but then also deploy her work with it.

I mentioned earlier in this call, we previously were down to a single day of releases due to the timing. We're up to three release days per week, and our new version of the repository, as of this week, we're over sixteen hundred pull requests that we've managed through this CI pipeline.

All of that is great, but as I'd mentioned, we've still got places we can grow and further that we can advance.

In college, I heard from a professor always be learning, and it stuck with me even if I was doing that before and just didn't really have a phrase tied to it. I like to to reiterate that and just in wrapping on the presentation.

Tools like Trailhead, DevOps Launchpad, and even a gear set trial have been phenomenal for us to learn. Trailhead and DevOps Launchpad lets you learn from courses and videos, but a combination of those tools and Gearset's trial also gives you a way to get your hands on these applications and give it a try. Personally, I learn best from the mistakes that I've made and trying things to see what fails or what works. So having tools like that that let me take what they teach and put it into practice have have been tremendous.

With that, thanks everyone for for listening to my presentation, and I'll turn it back over to Amy.

Awesome. Thank you so much, Jeremy.

We've had ton of questions coming on the q and a, so I'm just gonna pull that up here. We'll get some of these answered.

Cool.

So our first question is from, Lauren who asks, yeah. This is a good one. What tips do you have for onboarding new team members?

She mentioned that you said about your intern, and new team members into the CICD process.

Yeah. So, with that, I would definitely recommend any feature like DevOps Launchpad has a fundamentals course. I think that would be great. But getting them familiarized with the language really helps a lot because I know whenever I was working with our intern, it was a lot of back and forth of, like, do you know what CICD means?

Do you know what DevOps is? Do you know what, SDLC stands for? Do you know what a push and a pull and a feature and a hotfix? And, fortunately, she had a lot of that background from her college experience, but establishing that lexicon will definitely make it a lot easier for you to talk to the team member and then show them how you're working through things.

But it is it will be some back and forth, like, ask where they are and then help catch them up to where you are. But using tools like Launchpad to give them a place to start will be helpful. And then for me, the quickest thing was doing just a show and tell, like, sitting down with her and going through a session. We we sat down on a release day, and I showed her where everything was, how it got there, and then how we were able to use the pipeline to to finish the release to prod.

Yeah. Awesome awesome advice, and an awesome example of onboarding new team members as well. We've had a few questions come up, just in the chat. I don't know if you wanna have a look here, Jeremy, just about, users, especially, like, how many regular users, like, where you I think you broke down the list of all your Salesforce users and the Salesforce team size.

This slide.

Yeah. That one. Yeah. Thorburn asked how many regular users, were you using for that Salesforce team size?

Yeah. I see a couple related questions. I'll I'll try to combine and just give a a quick overview. So we do have a single production instance that we support, and and that's been great. It it is obviously growing, and there are challenges with those, but I think that's still the the proper path forward for us because there's not compliance or regulatory reasons for anything additional.

In that org, we support roughly thirteen hundred internal users, but we also have our company intranet built on, Salesforce and an experienced cloud site. That's actually one of the project teams we support outside of our platform team. So they manage and build our company's Internet. That one supports, around thirty six thousand team members, logging in to the company portal to get access to HR and benefits information, to do their time clock if they're hourly, to get updates from the company. That kind of stuff is is hosted on the Internet.

But, yeah, that's the org and the amount. And then the sixteen team members that are on our platform team, We support the core of the platform, but then a couple of our projects have been divided off and have their own teams. And so that's the the project teams I mentioned there, there's a team of, like, thirty other devs and admins that we support for a different sales division in our company.

The Internet team has a few devs and admins there that we support. Our implementation partner projects that we've supported over the years have been upwards of sixty to eighty devs and admins we support with the pipeline on top of the work that we're doing for the org, for the verticals that we're responsible for.

Yeah. Amazing. I think you've, yeah, hopefully, we've answered Sean's question there as well, I think as well. Fantastic, Jeremy.

So you're talking a lot about you guys have scaled from, like, small team to a much bigger team now.

Yes.

But we have had a question come in from Michelle in the q and a, which, does ask more about small teams.

They say, I'm on a small Salesforce team, only four people. Don't wanna overcomplicate DevOps, but I do know it would be more helpful to do more. What recommendations would you have for a smaller team, especially when we're pulled in lots of different directions and not focused on any large projects?

Mhmm.

I I can at least say from my experience, one thing that was very helpful for us was, the leadership we had when shifting from the manual compare and deploy to the pipeline. They helped establish a lot of guardrails for what we were doing, helped deflect a lot of priorities to make sure that, at the time, I was the principal engineer. So I I was tasked with building this out.

I will say with a smaller team that it to me, it sounds ideal because that gives you a really close knit group to take on this journey with you to get them learning the things that you're learning as you build them out, learning the the trial and error. But for the advice, I would say if you can, like, prioritize getting it built, getting it tested as you go, very agile methodology. Like, you don't have to build it and release it all as a big bang. You can build out the CI jobs and test out how you run those.

Like, even even doing what we did along the way of, like, manually releasing those, see how that works, see how everyone gets comfortable with committing to the repo, learning the pool reviews and that. And then once you have those, then that helps you bridge that connection to say, okay. The next step would be to automate this where it's going to do it for us as part of the pipeline. And maybe you automate your DevBox to a partial copy and full copy, but don't put prod in the pipeline yet.

Like, that'll help you automate your lower environments, and you can still manage your releases to production. But then once you're ready, you can bring that into the pipeline too.

Yeah. Fantastic advice. We've got so many questions here. I think, Darren we won't have time to answer your question in the chat directly but I think a lot of what Darren is saying about scaling and starting with one aspect at a time will really help you with that, support that complex environment just as much as small teams who are trying to scale as well.

We have got time for one more question.

Yeah. So many good questions coming in. Sorry, guys. If we don't get time to answer your question today, pop me an email at team at devilst launchpad dot com, and we will get round to it. I I can reply to to you. I can chat with Jeremy about answering some more questions.

Last question, how long did it take for your team to learn and implement CICD? Like, how long did that what did that look like for you?

We gave ourselves a full gear to to do that.

I would say we at least had a rudimentary pipeline running within four to six months, actively running. But to get everyone comfortable with it and ensure that we were trusting all the aspects of it, I I would say at least a full year for the scale that we were at at that time because I we were also catching up to the scale that we were running our, manual process with.

If you're not dealing with as much as we were as far as priorities and and different things taking our time, I think you could do it in a much shorter time frame than what we did. But that allowed us to have the the comfort to trial and error it to fail as much as we did and learn from that and then take the next step to improve it. So, but, yeah, at at least for us, it was we did it within that full year where we started tackling it.

Awesome. No. Awesome. I'm gonna run over by a minute because we have one last question that I did think was a fantastic question.

Someone in the chat anonymously asks, how would you suggest approaching upper management about switching to a CICD model? And this is something I asked as well about, how can you get buy in, right, from from your managers, from your team for CICD? And and this person specifically says we have a small team, and moving, wasn't an issue until this past year.

Like, like you, they had a ton of projects, and they know they can benefit from this. So what's your advice on on getting that buy in?

Yeah. Unfortunately, for us, our director at the time, he he was absolutely in on it. He had a tech background, and he was really pushing for it. So having someone in your corner always helps.

I I know that's not something that everybody gets. I know that that changes for everyone. As far as what I learned, what I if I could have gone back and documented, I I feel like this would be such solid information for me to have had was the time that it's taking you in your current process. Like, documenting that it was taking us four to eight hours, like, having that proof of saying here, we started building this today.

We finished the package tonight. We started validation. The next day, it took x amount of hours to run. It took us that to release.

So, like, we could have shown, you know, we're taking, you know, a good three days to just get a release ready because of the scale that we're running at and then shifting it to the CI jobs that helped improve that speed so I could have shown how much we shaved off just doing that. And then today, it it's unfortunately anecdotal because I don't have that evidence from the way we did this process. But when it gets brought up, anytime it's question about the pipeline, I always go back to, like, if we were doing this with manual compare and deploy, what we do today in just a few hours for our release would take us full weeks to get ready for.

And if we were doing it even worse in change sets, that to me is so exponentially larger than what we were doing even with the compare and deploy. I mean, it would have been a couple weeks to be ready for a release. So if you're starting this process now, that would be my advice is, like, document all of the steps that you're going through, put some time to those steps, and then you can multiply that by how many ever team members are involved when we're doing a few admins here and a day of here to get all of that built out. Like, that will just give you, to me, really good evidence to say, like, we can take this and we can shrink it to a much faster process when we put something like a pipeline in place.

Yeah. No. That's absolutely awesome advice.

And we are gonna be sending a follow-up email out around about this time tomorrow, which will have, a CICD ebook in there, which I'm I know has very good advice about getting buy in, and about starting that journey within your teams as well. So do look out for that. But that is all we have time for today. So, folks, you've slightly run over, but you all had some fabulous questions, so I knew you would. As I mentioned, if we don't get round if we didn't get round to answering your question today, just reach out. The email is team at dev ops launchpad dot com, or you can reply to that email we'll be sending out with the recording of this webinar round about this time tomorrow. Just reply, and I'll get back to you.

And just a reminder, if you aren't currently a DevOps Launchpad user, you can go check out all of our free Salesforce specific courses and certifications over at dev ops launchpad dot com. And as Jeremy mentioned too, you can start to put those CICD and other DevOps best practices into action with a Gear Sets free trial, as well. So I popped both of those links for you just in the chat there. But, again, there'll be links in the email tomorrow.

So thank you so much all for joining. And once again, a huge, huge thank you to Jeremy for, hosting and presenting today's session. We hope you found it super insightful, and we'll see you all again very soon. Thanks so much, and take care, everyone.

Thanks, everybody.