function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Ken KoellnerKen Koellner 

Source Control policy for developers working in the same sandbox

Does anyone --
  • develope with a team of at least 1/2 dozen developers.
  • Have a large org with lots of code and complex data that must be setup before any real work can be done.
  • Use a single development sandbox for all developers.
  • Use a source control for code.
We have found it prohibitive to set up a sandbox for every developer because of the amount of setup data need for developers to do real work.  (Sandbox-to-sandbox copy would fix that; rumor is it's coming but not for 6-12 months.  So we all work in one sandbox.  We've never implemented source control as then there'd be an ambiguity over whether to get a module from source control or the sandbox org before editing.  The warning you get in the IDE before saving to the org would no longer be meaningful.  So developers would have to be maticuous about following some sort of procedure or they could either overwrite others' changes or fail to get there own changes saved properly.

Has anyone solved this problem and devised a strategy for using source control when multiple users are working in the same sandbox?
 
Alain CabonAlain Cabon
Interesting question and the sandbox-to-sandbox copy is still restricted to pilot projects.

You are using Git probably.

http://gitolite.com/gitolite/locking.html#
https://www.packtpub.com/hardware-and-creative/gitolite-essentials
https://github.com/sitaramc

That would be interesting if someone has already used the locking of file with gitolite or SVN instead of using Git basically and could give the feedback here.

Apache Subversion (svn) is an interesting alternative to Git with its lock communication.

Lock Communicationhttp://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html

SVN versus Git: https://svnvsgit.com/

 
Tam TTam T
I am hoping you might have already moved away from multiple developers working on the same sandbox as this definitely not going to scale. Your sandbox data problem can be solved via a Post Sandbox Refresh script that populates test data from a CSV file. More information here: https://releasenotes.docs.salesforce.com/en-us/spring16/release-notes/rn_deployment_sandbox_postcopy_script.htm

If you have 1/2 dozen developers, I don't think you can avoid source control, it is probably the only option that works. Having said that, leveraging source control comes with overhead and the unique declaritive aspect of Salesforce makes this even more challenging. 

I wrote a blog on things that I've learnt working with Salesforce & source control for the past 6 years. Hope this helps.
https://medium.com/@clickdeploy_team/salesforce-release-management-best-practices-4255ad7c7f63