Jeremy Foster · 28th August 2025

From change sets to CI/CD: a Salesforce DevOps success story

In this blog post, Jeremy Foster, Manager of Salesforce Development at Pilot Company, shares his team’s journey from the frustrations of manual change sets, to learning modern continuous integration and delivery (CI/CD) best practices through DevOps Launchpad, and ultimately implementing scalable CI pipelines with Gearset. He walks through each stage of that transformation, discussing how CI/CD enabled faster, safer, and more collaborative delivery across multiple teams.

Want to hear the full story? You can watch the webinar here for an in-depth breakdown of Jeremy’s journey.

Where our CI/CD journey began

When I first stepped into Salesforce development nearly a decade ago, I was surprised by how manual the processes were. Despite Salesforce being a cloud-first platform, it lacked built-in support for source control/version control, CI/CD, or scalable release pipelines. Fast forward to today, our team at Pilot has built out a robust CI/CD pipeline using Gearset, supported by best practices I’ve learned along the way — including plenty from resources like DevOps Launchpad.

The problem with change sets

Like many Salesforce teams, we started with change sets — the default option for managing deployments. But they were time-consuming, error-prone, and hard to scale. We had to manually track changes, and if something was missed, we’d have to rebuild the package from scratch. Without version control, automated testing, or observability, we lacked visibility and trust in our deployments.

Looking back, we were spending 4–8 hours a day just preparing packages for deployment across different teams. This approach wasn’t scalable. And it was clear that comfort had become a bottleneck.

From manual comparisons to automation

In 2019, we adopted Gearset, starting with manual compare and deploy. This already felt like a leap forward — we gained visibility into metadata differences, avoided duplicate work, and significantly reduced deployment errors.

But as demand for Salesforce development grew, our manual deployment process became a blocker again. That’s when we started exploring CI/CD more seriously — and I’m glad we did.

Building a CI/CD culture, not just a pipeline

Implementing CI/CD is as much about people as it is about tooling. Our pipeline wasn’t built overnight. It evolved as team members learned how to use Gearset, adopted version control best practices, and got comfortable with automation. We started with isolated continuous integration jobs and gradually connected them into a true multi-stage pipeline — from development to partial and full copy sandboxes, and finally to production.

To get there, we had to question our assumptions. One of the hardest (but most valuable) decisions we made was migrating from the old Metadata API format to a new DX-format repository. It felt risky, but it unlocked better scalability and made our pipeline much easier to maintain.

We also used DevOps Launchpad’s training to embrace and implement key best practices for Salesforce CI/CD, including:

We found many of these lessons in DevOps Launchpad’s CI/CD for Salesforce course. I’ve personally revisited this training recently and recommended it to my team to deepen their understanding — especially the modules on version control, branching strategies, and continuous validation.

Overall, by embracing CI/CD within our team, we were able to:

  • Move faster, releasing 3 times per week
  • Support 4 project teams and 3 implementation partners
  • Manage over 1,600 pull requests (just in our DX-format repo!)
  • Build a scalable, automated deployment pipeline that all team members could contribute to

Making CI/CD accessible to everyone

One of my proudest moments was seeing how accessible our CI/CD pipeline had become. Even our intern last summer learned how to use it and successfully managed releases. That speaks volumes about the simplicity and reliability we’ve built into the process — with the help of tools like Gearset and learning platforms like DevOps Launchpad.

If you’re onboarding new team members or helping your team transition from change sets, start with structured learning. I recommend starting with the fundamentals and best practices behind version control, git branching, and CI/CD, before moving on to the Gearset Automation Certificate and Gearset’s CI/CD ebook, which both provide a deeper dive into building and maintaining CI pipelines.

What’s next: monitoring, observability, and continuous learning

At Pilot Company our current CI/CD setup has taken us far, but we’re aiming higher. Our next steps include:

And through it all, we’ll keep learning. The biggest improvements often come from mistakes or friction points. That’s why I believe in revisiting learning tools regularly and sharing knowledge across the team.

Answering some of your CI/CD questions

What tips do you have for onboarding new team members into the CI/CD process?

  • Start with the language: establishing a shared lexicon early helps reduce friction and misunderstandings. Make sure they understand key terms — not just from a CI/CD perspective, but also how your implementation specifically works.
  • Meet them where they learn best: for visual learners, walk through the pipeline in real time. For hands-on learners, guide them through creating a small change — even a dummy one they can delete. Knowing how to reverse a change is just as valuable as knowing how to make one.
  • Document your process: share internal documentation that outlines your CI/CD flow, naming conventions, environments, and review processes.
  • Support self-directed learning: I recommend giving learners access to tools like DevOps Launchpad, Trailhead, Gearset’s free trial, GitHub Learn, and other online resources that reinforce your approach.

How did you get buy-in from the team to move away from change sets?

Honestly, it didn’t take much effort. When we first adopted Gearset, we were a small team of five. Four of us had years of Salesforce experience and immediately saw the improvement in using Gearset’s compare and deploy.

The one team member who was new to Salesforce was understandably hesitant. So I ran a side-by-side demo. We made simple dummy changes and deployed them both via change sets and Gearset’s compare and deploy. I even simulated worst-case scenarios to show what happens when you forget components. By the end, he was fully on board — impressed by the time saved, the better UX, and the clarity Gearset provided.

How long did it take to go from change sets to a full CI/CD pipeline?

Roughly a year — including all the trial and error, day-to-day work, and a period of running the pipeline alongside manual processes to build trust in it.

What advice would you give to teams still using change sets?

  • With kindness: it’s time to move on. Change sets served a purpose, but compare & deploy is a low-barrier entry point with far more power. You can build better processes just by switching to that.
  • Try a simple trial: do a small deployment side-by-side in both change sets and Gearset. That alone will highlight the difference in speed, clarity, and reliability.

What would you do differently if you were starting again?

  • Track metrics from day one: We know our process has improved, but it’s mostly anecdotal. Having solid data would help showcase that impact even more.
  • Fail faster: I was hesitant in the early stages of setting up CI jobs and pipelines, even though I had the tools and understanding. Looking back, I should’ve trusted that experience sooner and sought more real-life advice from Gearset folks earlier on.

How did you migrate from the Metadata API format to Salesforce DX?

It came out of a brainstorming session. Our original repo wasn’t 1:1 with our orgs, and maintaining it was becoming unmanageable.

Rather than spend time cleaning up that legacy repo, we started fresh — spinning up a new DX-format repo directly from the orgs we trusted. It was a big call, but it paid off massively in long-term stability and scalability.

What’s your current Git branching strategy?

We use Gearset’s Pipelines branching model (similar to the expanded branching strategy), which works well for us and aligns closely with GitFlow. We still use feature/, hotfix/, and release/ branches — just with an added promotion/ branch for the pipeline flow.

How do you keep environments in sync?

Gearset’s back propagation and monitoring jobs help a lot. We also use GitHub for version control, and run regular manual checks to ensure orgs, environments, and the repo stay healthy and aligned.

Are you using scratch orgs or still on sandboxes?

We’re currently using sandboxes, although we’ve experimented with DX packaging. We’re actively moving away from scratch orgs for now.

How do you handle hotfixes in your CI/CD pipeline?

We follow the hotfix branching model. We create a branch from main, develop and test the fix, deploy to production, and let Gearset generate back propagation pull requests. That keeps all lower environments in sync automatically.

How did you make the case for investing in Gearset and CI/CD tools?

I was fortunate — our leadership had already chosen Gearset after evaluating other tools. Once I got hands-on, I built trust in the tool, and later helped push for CI/CD adoption.

These days, my role is to demonstrate continued ROI and value — but Gearset’s impact on our delivery speed and scale makes that easy.

Any advice for supporting complex environments with multiple orgs or apps?

Start small. Choose one org or app and build a pipeline there to prove the value. Trust builds momentum — and a solid implementation will help you scale across teams. As the saying goes: “A journey of a thousand miles begins with a single step.”

Any tips for small teams getting started with CI/CD?

We started small — just 3–5 people — and built from there. Our pipeline now supports over 16 internal team members and multiple implementation partners. The path we took is scalable and adaptable for teams of any size.

Final thoughts

If you’re still using change sets or stuck in manual deployment workflows, it’s never too late to start your CI/CD journey. Question everything, embrace the learning curve, and take incremental steps. The payoff is worth it — faster delivery, higher quality, and a more empowered team.

If you want to get started with CI/CD for Salesforce, check out this list of resources below. Good luck!