A CI/CD pipeline for Salesforce that works out of the box

A CI/CD pipeline for Salesforce that works out of the box

Eliza Pepper on

Share with

LinkedIn
Twitter

CI/CD is a real game-changer for the Salesforce ecosystem. In fact, it’s at the heart of DevOps, helping teams to achieve faster, more reliable development and release cycles. But while most teams say they want to implement CI/CD for Salesforce, many struggle to see success.

Tooling is a common stumbling block. If you’ve used automation tools to build CI/CD pipelines to automate deployments for other platforms, it’s natural to try the same for Salesforce.

But Salesforce isn’t like other platforms. In this article, we’ll unpack why Salesforce is different and how Gearset can help as a purpose-built solution for Salesforce. You might also want to download our ebook on Salesforce CI/CD, which covers a range of related topics.

The benefits of Salesforce CI/CD make it worthwhile

In the face of any challenge, it’s always worth remembering why it matters to solve it. CI/CD is about regular releases of incremental improvements, helping you get new features into the hands of your end users quickly and ultimately getting more out of Salesforce for the whole business.

Salesforce CI/CD has many benefits, including:

  • Faster delivery of added value to end users
  • Tighter feedback loops within an agile, user-driven development cycle
  • More reliable and battle-tested release processes
  • Improved visibility and collaboration around your Salesforce pipeline
  • Fewer bugs in production due to smaller, less risky releases
  • Safer options for rollback, and less downtime as a result
  • Better ability to run multiple projects at the same time

The stages of a Salesforce CI/CD process

It’s common advice to think of CI/CD pipelines in terms of build, test, and deploy phases. But when it comes to Salesforce, things are a little different. A Salesforce environment is essentially the compiler and runtime for your code, so validating and/or deploying to an environment is the only way to make sure your latest changes can be built and deployed.

The diagram below shows a basic example of a Salesforce CI/CD process. Declarative developers (usually admins) and programmatic developers can each make metadata changes that are committed to branches and pushed to the remote Git repository.

When a pull request is merged into the main branch on the remote repository, automation jobs are triggered, deploying from the main branch to multiple environments. Testing, static code analysis, and more can be built into the automation jobs that deploy and validate the latest code.

Workflow diagram showing CI/CD with a simple feature branching strategy

In practice, many Salesforce teams need a more sophisticated Git branching strategy to manage their development lifecycle, balancing speed and stability. It’s common to use persistent Git branches that map to Salesforce orgs, for example — as we’ll cover in a little more detail later in this article.

Which kind of CI/CD solution?

Teams looking to automate deployments for Salesforce have two main options: standard cross-platform tools or Salesforce-specific solutions. In essence, the question is whether to build or buy.

Standard CI/CD tools

If you’re already using CI/CD tools to manage releases for other platforms, it’s natural to try applying the same toolset to Salesforce DevOps.

There are standard pipeline tools, built into version control, such as Azure DevOps, Bitbucket Pipelines, GitHub Actions and GitLab CI/CD. There are also cross-platform automation tools like Jenkins, CircleCI, TeamCity, Bamboo and Travis CI. Standard automation tools can also be used to orchestrate UX or Lightning Web Components testing, by integrating services like Selenium or Jest.

However, there are three main drawbacks to using cross-platform CI/CD tools for your Salesforce release cycle:

1. Slow setup

Implementing a do-it-yourself pipeline for Salesforce is no mean feat. As with any CI/CD pipeline, it requires DevOps expertise. It also involves using Salesforce DX and the Salesforce CLI. Salesforce teams switching to Gearset tell us they invested around 90 hours in the initial setup of a self-built pipeline — and that’s just putting the basic CI/CD workflow in place. More time is needed to set up static code analysis, project or issue tracking, deployment scheduling and notification integrations.

2. Costly maintenance

Once a pipeline has been set up, managing scripts, automation tools, servers and authentication methods all takes time and resources. Teams sink a lot of time tweaking their automation process whenever they need to add new environments, roll back a release, or reconfigure deployment scripts based on a particular set of metadata. The Salesforce platform itself is always changing, often breaking CI/CD pipelines built with cross-platform automation tools.

3. Brittle automation

Salesforce is a unique platform, and deploying via the Metadata API isn’t always plain sailing. In fact, 80% of Salesforce teams say they regularly see CI builds fail, meaning they need to unblock their automation manually. All of this means time spent on managing the process rather than on building and shipping features to end users.

A CI/CD solution built for Salesforce

The alternative to these standard do-it-yourself tools is to use a CI/CD solution built to handle all the complexities of your Salesforce deployments. Gearset offers a complete DevOps platform with all the functionality you need for an efficient and resilient release pipeline.

Unlike other options, Gearset makes Salesforce CI/CD: quick and intuitive to set up; pain-free to maintain; easy to see success.

Quick and intuitive setup

The first thing you’ll notice with Gearset is just how easy it is to get started. What can take 90 hours to build with generic tools takes just 30 minutes in Gearset.

You can create and manage individual CI jobs in Gearset to build pretty much any CI/CD pipeline you choose. Our recommended approach is to use Pipelines to visualize and manage your team’s entire workflow.

When you configure CI jobs, you’ll be able to meet your exact use case with the following range of options:

  • Integrate with your Git hosting provider.
  • Set the source and target for the job.
  • Choose whether the job deploys or validates your changes.
  • Set up validation of pull requests against the target.
  • Deploy the delta or sync everything.
  • Choose whether the job runs on a schedule or is triggered by changes on the branch.
  • Decide which combination of new, changed and deleted items should be deployed.
  • Determine the exact metadata types that will be deployed.
  • Select which unit tests to run.
  • Perform static code analysis and determine which failures should prevent deployment.
  • Set up outgoing webhooks to other systems.
  • Configure which of Gearset’s problem analyzers are automatically applied.
  • Set up notifications to Slack, MS Teams etc.

When it comes to connecting up your release pipeline end to end, using Pipelines makes the whole process intuitive. You simply string together a series of automation jobs using a drag-and-drop interface.

Your whole team then has a bird’s eye view of your CI/CD pipeline, showing the status of all environments and pull requests at a glance. Any changes made in your VCS will be shown in pipelines and vice versa. Merging changes automatically opens pull requests for forward or back promotion to other environments, so it’s easy to keep everything in sync.

Gearset screenshot: Merging changes automatically opens pull requests for forward or back promotion to other environments

If you use the Pipelines functionality in Gearset to build your CI/CD process, you’ll need a persistent Git branch for each Salesforce org in your pipeline. The diagram below shows an example of how the branching model works in Pipelines, and you can find out more in our documentation.

You can set up your pipeline to support releasing each feature on demand. Or if you have a set release cadence, you can use a release branch model to combine features and release on your schedule.

Workflow diagram: An illustration of the branching strategy used by Gearset Pipelines

Painless maintenance

Once you’ve built your CI/CD process in Gearset, maintenance is minimal. You can easily tweak and scale your team’s workflow without getting bogged down in build agents, deployment scripts, or SFDX commands. When there are platform upgrades on Salesforce, new metadata types, or known issues, Gearset will build support for those into the platform. You won’t need to dedicate team members to maintaining your CI/CD pipeline full time.

Reliable and successful deployments

Since Gearset is built specifically to handle Salesforce metadata, it makes sure your deployments succeed first time. Gearset can automatically resolve merge conflicts, and automatically fix common deployment issues, such as missing dependencies.

Teams using Gearset have a deployment success rate of 97% — which compares with roughly 50% for deployments using native tools on Salesforce. When switching from standard CI/CD tools to Gearset, our customers have reported dramatic reductions in the time taken for each release. For example, Zurich, a leading insurance enterprise, delivered in under 2 hours with Gearset what had taken an entire weekend before.

Zurich logo

The painless way to implement Salesforce CI/CD

Successfully adopting CI/CD is integral to DevOps success and unlocks the benefits of agile working, so it’s important to find the right solution for your team. To arrange a tailored demo of Gearset, get in touch today. And you can always sign up for a free 30-day trial of the whole platform — it really does work out of the box!

For an in-depth guide to setting up a CI/CD pipeline for Salesforce, addressing all the key questions about release automation, download our free ebook on CI/CD for Salesforce.

Try all of Gearset for free