How to build a Salesforce CI/CD pipeline using GitLab

Adopting CI/CD is a core step in taking your Salesforce DevOps to the next level. If your team is already using a version control system and manually pushing deployments through a source-driven workflow, introducing automation is the logical next move.

But if the idea of automating your Salesforce deployments feels daunting, Gearset can help make the process straightforward. In this post, we’ll explore how Gearset integrates seamlessly with GitLab to build an automated GitLab Salesforce CI/CD pipeline. You’ll learn how easy it is to set up continuous deployments directly from your GitLab repository, without needing to use the Salesforce CLI — boosting collaboration, catching issues early, and streamlining your release process.

If you’re using GitHub, GitHub Enterprise, or Azure DevOps instead of GitLab — Gearset supports those too, with the same seamless integration and automation.

The benefits of version control and CI/CD

A version control system (VCS), like Git, is foundational to continuous integration and continuous delivery (CI/CD). Version control helps development teams track, combine, and manage changes to source code without accidentally overwriting each other’s work. It also makes it easy to roll back to an earlier version and supports better teamwork by keeping everyone in sync.

The flexibility of version control comes from branching — separating work into multiple streams of development so that changes are made on isolated branches, instead of in shared sandboxes. You can adapt your branching strategy to suit how your team works best.

With version control in place as your source of truth, CI/CD is the next step to introduce automation into your release pipeline. Continuous integration (CI) keeps code modifications moving towards production automatically, progressing changes through the release cycle and integrating them into target environments so they can be tested and deployed safely. Continuous delivery (CD) helps you release in small, frequent batches — reducing risk and getting improvements to end users faster.

Jeremy Foster, Manager of Salesforce Development at The Pilot Company, explains the difference CI/CD made for his team: “It sometimes took an entire day just to put together a project and validate it, simply due to the size of components involved in the process.” Adopting a CI pipeline transformed their Salesforce workflow, bringing speed and simplicity to complex deployments.

Some key benefits of CI/CD include:

• An iterative, user-driven development cycle
• Automated testing and validation that reduce the risk of bugs in production
• Greater transparency and improved communication across the release pipeline
• Easier and safer rollbacks with minimal downtime
• Increased capacity to handle multiple projects simultaneously

Version control and CI/CD are important steps in the process of adopting the complete DevOps lifecycle — bringing structure, automation, and consistency into the development process.

If you’d like to learn more about CI/CD for Salesforce, download our ebook:

Why choose GitLab as your version control system

There are different types of version control, but Git is by far the most popular among Salesforce teams. If you’re using Git, there are several platforms to choose from — and GitLab is one of the most flexible.

GitLab offers both a free cloud-hosted platform and an open-source Community Edition you can self-host. Every GitLab project includes a Git repository, issue tracking, merge requests, and integrated CI/CD — all in one place.

For enterprise Salesforce teams, GitLab’s ability to be self-hosted makes it easy to meet internal security and compliance needs. It was also one of the first Git platforms to offer built-in CI/CD capabilities, which means it’s had more time to mature and earn trust as a reliable option for automated deployments.

Gearset integrates easily with GitLab using secure OAuth — the same approach used to connect Salesforce orgs. That means you can track and deploy changes from your GitLab repo through your full release pipeline, regardless of where the merge request was opened.

Best practices for setting up a CI/CD pipeline

Setting up CI/CD for Salesforce isn’t as straightforward as copying a typical software pipeline. Because Salesforce metadata is tightly coupled to its environment — and changes can come from both declarative and programmatic sources — you need to account for some platform-specific quirks.

In most platforms, build and test steps run independently of deployment. But in Salesforce, environments serve as both the compiler and the runtime — meaning you often need to deploy changes just to validate them.

With that in mind, here are some key considerations for setting up a CI/CD pipeline in Salesforce:

• Define a clear branching strategy and sandbox setup: You need a branching strategy that works for your environments and your team’s processes. If you’re using Gearset Pipelines, it’s best to align stable GitLab branches — like main, staging, or uat — with long-lived Salesforce environments. Scratch orgs and short-lived feature branches can still be useful for development and early testing, but tying persistent sandboxes to stable branches gives you better automation, traceability, and control. And if you’re using Gearset Releases to manage bundles of work, there’s no need to maintain separate release/* branches in Git — the release metadata is handled directly in Gearset.
• Keep environments in sync: Regularly sync your environments to minimize metadata drift. Gearset Pipelines helps maintain this consistency by ensuring changes are automatically delivered across environments.
• Merge early and often: The longer a branch stays open, the more the main branch is likely to evolve in the meantime — increasing the chances of merge conflicts, outdated code, and integration issues. Regularly syncing and merging helps keep changes aligned and reduces the risk of surprises later in the release cycle.
• Shift testing left: Automate validation and testing as early as possible to identify bugs and fix problems before they reach staging. You can also integrate Code reviews (powered by Clayton) directly into your pipeline, giving you automated feedback on quality, security, and best practices.
• Maintain a deployable main branch: Your main branch should always be in a state where it can trigger production deployments. Use Gearset’s automatic validation to ensure any changes merged into main are tested and ready for release. This is key to achieving the fast, low-risk releases that continuous delivery ensures — with work shipped in small, verified increments rather than large, disruptive batches.
• Implement role-based access controls: Manage team permissions using Gearset’s built-in access control to determine who has access to specific orgs, pipelines, and CI jobs. Pair this with GitLab’s project-level permissions to enforce governance and security across your CI/CD flow.
• Enforce branch protection policies: Use GitLab’s branch protection to safeguard key branches — like main or any long-lived environment branches. GitLab splits protections across different areas, so be sure to configure both branch protection rules and merge request approval rules. Requiring approvals, successful pipeline runs, and code reviews before merging helps maintain code quality and prevents accidental or unreviewed changes.
• Monitor and audit deployments: Gearset provides detailed audit logs and deployment histories, making it easy to trace what changed, when, and why. Use this data to stay compliant, troubleshoot issues, or optimize your pipeline over time. GitLab’s integrated activity and commit history further complements this visibility.

Can you build a Salesforce CI/CD pipeline only using GitLab?

Yes — you can use GitLab CI/CD and GitLab Pipelines along with the Salesforce CLI (formerly SFDX) to build your pipeline. Although this won’t be straightforward, as you’ll need to handle everything yourself: scripting the entire deployment flow, setting up JWT-based authentication, enabling and connecting to a Dev Hub org to manage scratch orgs, and defining all CI logic in a custom .gitlab-ci.yml.

While it’s technically doable, it’s also highly manual and comes with a steep learning curve. One mistake in your pipeline config — a missing environment variable, an outdated CLI version, or a mismatched encryption key — can cause your pipeline to fail. You’ll also need to handle destructive changes, manage test execution behavior, and troubleshoot edge cases across different orgs and GitLab runners — isolated environments that execute your CI/CD jobs.

For teams with dedicated DevOps engineers and plenty of time, that might be fine. But for most teams, it’s a high-effort and high-cost option. Instead, a purpose-built solution for Salesforce development, like Salesforce DevOps Center or a more complete solution like Gearset, drastically reduces setup time, simplifies authentication and org management, and adds guardrails around every part of the continuous deployment process.

How does Gearset enhance Salesforce CI/CD with GitLab

Gearset connects directly to your GitLab repo and Salesforce orgs, and runs the pipeline steps — validations, deployments, tests — so there’s no need to install or configure any runners, or write manual scripts for deployment logic. You can configure CI jobs through Gearset’s UI, with full logging and history built in.

Using Gearset Pipelines means that as soon as a merge request is opened in GitLab, changes can be automatically pushed through your branching model. This could be from feature branches through integration and staging — and once merged into your main branch, Gearset can safely deploy the changes to production.

You don’t need to create a connected app or configure JWT-based authentication if you are using Gearset to deploy your changes to GitLab. Gearset manages all org authentication via secure OAuth — so there’s no need to upload certificates, manage tokens, or include scopes like “Perform requests at any time”. Unlike the Salesforce CLI alternative, Gearset also handles build testing automatically, validating deployments and running automated tests — with no need to manually script SF commands or set up custom CI jobs yourself. If your team also relies on external tools — like Selenium, Leapwork, or other GitLab-based test suites — you can trigger those workflows automatically.

In this walkthrough, we’ll show how you can connect GitLab as your source repository for your Salesforce pipeline in Gearset. You can sign up for a free 30-day trial of Gearset and follow along with these steps.

Create your GitLab project

Log in to your GitLab account. To create a new GitLab project, select New project. Choose whether to start from scratch, create from a template, or import an existing project. Name your project and set its visibility.

You can also configure your project at this point. If you already know how you want to structure your pipeline (for example, with main, release/*, or feature/* branches), it’s a good idea to set those up now so you can map them to your Salesforce environments in Gearset later.

Connect your repo

To connect your GitLab account to Gearset, head to the Source control and services page and click Connect to GitLab. If your GitLab repository is self-managed, you can find an integration walkthrough in our docs.

Authorize Gearset

Connect to GitLab will take you to GitLab’s OAuth page for authentication. Check that your organization has given Gearset access to your repo. Once you have access and are ready to connect to Gearset, click Authorize.

You’ll now be redirected back to Gearset and will be able to use GitLab branches as your source or target.

Add a new pipeline

Once you’ve connected your GitLab account to Gearset, you can create your pipeline. Under Continuous Delivery in the left-hand side menu, select Pipelines, then click Create new pipeline +. Follow the prompts to name your pipeline, set access permissions, and configure issue tracking.

Add a webhook

After creating your pipeline, click Add webhook to generate one automatically, or choose to set it up manually. This allows Gearset to sync with your GitLab repositories and branches in real-time.

Create your pipeline environments

To add stages to your pipeline that represent environments and automation jobs, click Create environment, select Create new environment/job and follow Gearset’s CI job wizard. To add more environments, click + Add in the top-right corner and choose Add static environment or Add developer sandbox.

Connect your pipeline

Now you have all your environments added into your pipeline, select Edit environments in the top-right corner. Drag and drop your environments into place, draw connectors to link them together, and when you’re done, click Save changes.

Once your pipeline is connected, you can enhance your GitLab CI/CD workflow by integrating test automation. Gearset’s Code reviews (powered by Clayton) will run static code analysis, automatically testing for issues in code quality and security whenever a merge request is opened in GitLab.

Gearset also works alongside leading test automation platforms like Provar and AccelQ, helping you expand beyond unit tests to full regression and UI testing. Combined with GitLab’s robust branch protections and real-time webhook updates, your pipeline becomes not just automated — but intelligent, secure, and reliable from commit to release.

Keep your pipeline flowing with continuous deployment

Now that you’ve set up your CI/CD pipeline using GitLab and Gearset, you’re ready to move faster with confidence — creating feature branches, creating pull requests, and automatically promoting changes across your Salesforce environments.

Gearset Pipelines makes it easy to build a reliable GitLab CI/CD process tailored to Salesforce, handling everything from validation and testing to deployment and rollback — no scripting required. Whether your release process is simple or complex, Pipelines helps your team stay in control at every stage.

Get started with GitLab and Gearset

Want to see it in action? Start a 30-day free trial of Gearset and begin automating your releases with GitLab today.