We (Team & Org.) are new in salesforce development and not sure if our infrastructure setup is right or not.

Current Setup:

  • We have a set of 3 developers working on one developer sandbox. The project is not yet deployed to production.
  • We are using Visual Studio Code/Salesforce DX/Salesforce Extension Pack for our development
  • We have also integrated the code (Apex classes and whatever present in default package.xml) from the dev sandbox into our Azure DevOps repo

Problem Statement: Let's say all the three developers are working one same class file and writing 3 different methods which they want to unit test. In VS Code to run the unit test, your code must be deployed to Org. If one of the developers deploy his code to sandbox and start unit testing another developer can not deploy or test his piece, because it will just overwrite in the sandbox.

We can use source control to merge first then deploy, but I think we should push code to source control only after unit testing.


  • How should we tackle this issue? We want all the developers to write and unit test first then we can push it to the Azure DevOps and finally deploy to the sandbox. Is it possible? If not what is the better and recommended way?

Thanks in advance!

  • 1
    Are scratch orgs something you're willing to consider? Seems like that feature fits pretty well with the problem you're trying to solve, and it should be pretty easy to adopt in what sounds like a pretty new org.
    – Derek F
    Jun 17 '20 at 20:37
  • 2
    Sharing sandboxes is definitely not best practice. Each developer should have their own isolated environment, preferably a scratch org. There are some great Trailhead modules on the "Org Development Model", "Package Development Model", and on setting up CI/CD with Salesforce DX that I definitely recommend.
    – David Reed
    Jun 17 '20 at 20:54
  • 1
    In a well-managed CI/CD lifecycle, unit tests should be running in a feature branch, in CI, before merging to master, and only code tested and merged to master should be allowed to deploy into a permanent org.
    – David Reed
    Jun 17 '20 at 20:55
  • Even if you don't deploy CI at this point, adopting the "sfdx, branch per work item and scratch org per work item" approach will remove all your headaches and ensure that each developer has a clean org for every work item they address, merging code back to master/main trunk only after full unit and other testing using the scratch org created solely for that work item and discarded after the work item is complete.
    – Phil W
    Jun 17 '20 at 21:05
  • 1
    Start here
    – Phil W
    Jun 17 '20 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.