How to use Bitbucket, GitLab, Azure DevOps, (or something else) with Salesforce DevOps Center

Chris Payne
OrgFlow
Published in
4 min readJun 23, 2022

It’s finally here — the public beta of Salesforce DevOps Center. DevOps Center is Salesforce’s long awaited (and delayed) next generation deployment and DevOps tool.

A screenshot of Salesforce DevOps Center.

I got hands-on with DevOps Center at TrailblazerDx ’22 and was lucky enough to talk in-depth with some of the team working on the product. One of the things that you’ll first notice is that DevOps Center only supports repositories in GitHub (and this does not include GitHub Enterprise Server). This is not an issue if you happen to use GitHub, but what if you use something else such as Bitbucket, GitLab, Azure DevOps, AWS Code Commit, Launchpad, a self hosted Git repository, or something else entirely?

Why does Salesforce DevOps Center only support GitHub at launch?

It comes down to two restrictions:

Firstly — DevOps Center runs ‘in the cloud’ (more specifically: a Heroku instance that the DevOps Center team maintain). This effectively rules out supporting Git repositories that are behind a firewall (such as an internal Git server or GitHub Enterprise Server. The only way that DevOps Center could communicate with these types of repository would be if rules were added to the firewall to allow traffic from the Heroku app itself. As far as I’m aware, Salesforce don’t publish the details that you’d need to enable this, and I wouldn’t expect support for this use case soon (if at all).

Secondly — The code that runs DevOps Center uses GitHub’s API to perform certain actions (such as creating a branch or a pull request). This API is specific to GitHub, and it can’t be used to perform these actions on other repository providers. In order to support another provider, Salesforce would have to build out support for the other provider’s APIs. This is problematic because it takes time and effort for the DevOps Center team to develop these integrations. Additionally — not all providers will support the required APIs, effectively ruling out support for those providers.

So, how can you run your Salesforce DevOps if you use a repository that is hosted outside of GitHub?

Option 1 — Mirroring

Mirroring is the action of taking the contents of one Git repository, and automatically copying it to another. There are a number of tools that can do this for you, and some Git repository providers have built in support (GitLab for example).

However, mirroring comes with a number of drawbacks:

  • You still need a GitHub repository as your go-between
  • You need to spend time and effort on setting up and maintaining your mirroring solution
  • Most mirroring solutions won’t mirror pull requests
  • Your Salesforce users will still need GitHub accounts
  • Mirroring can cause conflicts that are hard to resolve

Option 2 — Switch to GitHub

Moving an existing repository to GitHub is relatively straightforward, and if done correctly then you will be able maintain change history too.

Obviously this is not a small change for your organization, so you should consider all your options and the consequences before committing to this approach.

Option 3 — Don’t use DevOps Center

Salesforce DevOps Center is just one of many Salesforce DevOps tools available. You shouldn’t feel compelled to shoe-horn you DevOps process to fit DevOps Center, especially if that means making compromises.

OrgFlow, for example, supports every Git provider that I know of (including on-premise Git repositories accessible only from within your corporate network).

It does this by:

Firstly — Giving you the option to run OrgFlow on premise. This means that OrgFlow can communicate with Git repositories that are within an internal network and not open to the internet. This also comes with a couple of other advantages such as keeping your Salesforce metadata processing within your internal infrastructure.

Secondly — Sticking to ‘pure’ Git commands, and not relying on any proprietary APIs from GitHub or any other provider. This means that we can support any Git repository and we don’t have to waste time building out support for new providers.

You can sign up for a two month free trial of OrgFlow, and we have a Slack workspace that you can join for help, tips and tricks.

Final thoughts

Salesforce DevOps Center is a good start in the right direction for many Salesforce teams. However, you should be sure that DevOps Center is the right choice for you before committing to it for your Salesforce DevOps. The limitations that this product imposes on your tooling and process may make Salesforce DevOps Center a non-starter for some teams.

There are a handful of other good Salesforce DevOps tools out there on the market, and you should find the one that best meets your needs.

--

--