It has been a while since my first article introduced Ebury’s old Salesforce “Continuous Integration” flow, describing how we were using Change Sets and the problems we encountered. In this article I want to cover the various options we evaluated to improve our workflow, their pros and cons, and why we ultimately chose Salesforce Developer Experience (DX). It is worth mentioning that we were already using Jenkins to manage Continuous Integration for the rest of our engineering teams, so using it for Salesforce would be ideal.

Change Sets

There is not much more to say beyond my first article. They are great for small companies, sporadic changes or external consultancy work, but they are not the tool for a large in-house Salesforce technical department. In addition, they are really hard to automate.


The first alternative we looked at to start building our CI flow was the Ant Migration Tool, widely used for Salesforce deployments for years with great official documentation in Salesforce and a great & active community around it.

It would allow us to move the source of truth into the code, automate deployments including both code retrieval and deployment, remove manual and repetitive steps, and also perform destructive changes – such as deleting a field, which was something we had to do manually with Change Sets. We could also use it to import data sets in different environments

However, the main disadvantage we had here is that Salesforce had just released Salesforce DX, which was a game-changer in the Salesforce ecosystem and – while it was true that it was a green and still growing project – was much more powerful than ANT. It was also clear that this was the technology Salesforce were investing in, which left ANT as a kind of legacy technology with some limitations, like a reduced set of commands compared with DX and a lack of flexibility.

Third Parties

Many third parties can help you handle your CI flow, such as CopadoAutorabit or CircleCI. Those solutions are great and can bring many out-of-the-box features, but they all had 3 main problems:

  • They weren’t Salesforce DX: when we started thinking about the new CI flow, we were pretty clear we wanted to use Salesforce DX and scratch organisations but, as it was quite new, not all those tools had support yet.
  • Flexibility: if we want to do something custom, we would be tied to the tool’s capabilities, which could be very limiting in some cases.
  • Cost: it would mean an extra cost, which is not a problem itself, but it would have to be justified.

Salesforce DX (sfdx)

As already mentioned, Salesforce DX had been recently released and seemed like a game-changer, bringing many powerful capabilities and enough flexibility to support all the requirements we had. It was also a great Salesforce investment, with additional features being released regularly, such as Org Shapes and snapshots.

The main capabilities that convinced us were:

  • Source driven development: It would allow us to easily have everything in the repository: code, configuration and metadata. It has an sfdx format which is richer than previously. In the example (from the official documentation), you can see how granular the info is now in the repository.
before: custom objects and custom object translation in one big metadata file
Standard format
after: custom objects and custom object translations transformed into smaller bits
sfdx format
  • Agile development/testing. Salesforce DX brought a new kind of environment: Scratch Orgs. They can be quickly created and used as you want for development, testing, integration into the CI or executing your test suites.
  • Developer experience: Bringing many out-of-the-box amazing tools that made our life easier, such as the Salesforce Cli (official documentation), which quickly allowed us to manage scratch orgs, deploy/retrieve code, push data, execute tests, and much more.
  • Easy releases: sfdx format is great for development and testing, but can also easily transform it into the classic format to deploy into your sandboxes and production, so you can automate every single step of the Software Delivery Life Cycle.

It also had other features to help in dealing with large repositories like the Unlocked Packages to allows you to better distribute your code in different apps, avoiding the need to do a really deep slicing exercise in your code.


If you are still reading, you will almost certainly have the same thoughts as us: Salesforce DX was the clear choice. Maybe today we would have looked more deeply into other third parties as they all are now supporting Salesforce DX and scratch orgs, adding an improved developer experience over them, but we would certainly lose some flexibility even though they cover most of the scenarios we could think about.

In the next post, we will be sharing our first steps with Salesforce DX and (spoiler alert!) how it was not as easy as we thought it would be!

Join the team changing the future of FinTech

Apply now!