Version control within Salesforce can be quite a tricky topic, very quickly one will experience the conflict of knowing what is the source of truth within their organization. It seems the most educated responses on the topic always include CI integrations that help maintain some of this complexity... unfortunately they don't also come with step by step tutorials for setting up what can be a complicated structure.

Beyond these issues which have been discussed in other post, I specifically want to understand the best practices used when it comes to maintaining the versioning of different modules, components, or features within you Salesforce repository.

For example when creating a new business process you may have triggers, classes, objects, pages, etc., once that deliverable is ready for deployment I question how you handle versioning and maintaining these subsets (possibly using submodules, subtrees, other).

It would seem impossible to manage submodules (essentially separate repos) because the "sub-project" overlaps with everything (also deployment with submodules is brutal and likely not even possible with Salesforce). Classes and Triggers are ALL in the classes and triggers folders (no awareness of the project it belongs to)... and unfortunately I can't just create project-x directory with its own classes and triggers directory.

So now even though project-x is at version 1.0, while project-a is at version 7.0, the Salesforce repo as a whole is at version #.##.#### ??? These are all in one ever growing repo, but each business discipline has its own development road map, so how do you manage this? Or am I asking the wrong question and overthinking this with the wrong approach?

  • 4
    Great question and one I have always struggled with. Salesforce DX may take some of this pain away. I am a one man show and I find it difficult to do this let alone in a team. I find it impossible to create a patch say from a modified sandbox source (different from production) to fix a production issue then merge it all back into production and the modified sandbox code. Everytime I try my HEADs get messed up and I have to manually fix everything. For me, the safest way is a linear don't do Y until X is complete and don't even try to do Z yet. Looking forward to a good answer here.
    – Eric
    Nov 22, 2016 at 3:43
  • 1
    As an aside, while this is a broad topic, I think it benefits the entire community and hope it does not get closed.
    – Eric
    Nov 22, 2016 at 3:45
  • 1
    I agree I look forward to what DX will contribute to this, I met with some reps on the team at Dreamforce and essentially was told sorry for the tease because until it comes out there is really a comparable solution. Also, to my point, how is it even possible to manage a single repository with multiple project versions? Nov 22, 2016 at 3:52
  • This is a tough issue for sure. Salesforce and Git are hard to get working together reliably. DX is going to address part of the problem, but you are still going to have issues with declarative changes, and deployment will not be covered by DX. We've been doing a lot of research about this topic (we are building a hosted solution that will expose your Salesforce Metadata through a native Git interface). If you're interested, we blogged about Atlassian's Dreamforce talk about what they're doing. Nov 27, 2016 at 22:30

1 Answer 1


Salesforce DX is the future of source-code-driven development. Instead of spinning up Developer Orgs that you have to clean up, or Developer Sandboxes that take hours to populate, DX creates new sandboxes in a matter of seconds, can push a decent-sized code base in a few minutes, and can even script data loads for you, with relational data across many objects, and stored safely in your code repository.

For now, if you want to try and build your system today, you can go with this or this, but honestly, if you can wait until at least the beta of DX, you'll be far better off. We've been struggling trying to set up CI for months and code repository we can keep up to date for a year, and DX pretty much answered all of our problems overnight.

Of course, your mileage may vary, but I feel very privileged to be part of the pilot program. Assuming the production experience is even half of what we have in the pilot, we'd already have more than 100% boost in productivity. We often spend hours setting up an org just to try to answer a single problem in production that would take just an hour to solve if we didn't have to wait so long for the Sandbox queues.

Let's be clear here: in the future, your code repository will be your source of truth. Not a Sandbox, not even Production. You will pretty much be able to fast-forward and rewind your code with minimal fuss, and the spin-up time associated with creating new Developer Orgs or Sandboxes will virtually disappear. Even if the system ran 20 times slower in production than it does in the pilot, it'd still beat our current process by 10-20 times.

Not only will your source of truth be your own code repository, you'll also have new tools to reduce the time needed to retrieve and deploy code, run tests, and manage permissions in new development orgs from the command line. Also, there's new documentation for setting up with Jenkins or Heroku that will be available, meaning even a team of one should be able to set up a basic CI solution in just a few hours. One thing that they keep mentioning is that they intend for this to be a prescriptive solution (meaning, it's already a solved problem, and all you have to do is follow instructions).

And yes, we'll get the ability to store our code in sub-modules, and (hopefully, based on my feedback) be able to deploy just fragments of code to save even more time when setting up new orgs, especially when you only need to test one particular feature and don't feel like copying an extra 1000 units of code just to load the 5 that you need.

The pilot is closed, but be sure to sign up for future notifications. The future is coming, and it is awe-inspiring.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .