• Tam T
  • 0 Points
  • Member since 2018

  • Chatter
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 0
  • 3
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?
Today we do not have a release magament process for SFDC releases. I read a lot of articles on the subject but I don't find the best way. There is a lot of tools to do that : Flosum, AutoRABIT, Copado, CloudMax, sfOpticon, Force.com Migration Tool... 
We think to use the Migration tool with SVN and the dataloader to automate all the process and make Continuous Integration with Jenkins. The idea is that we would like to have :
- a sandbox for each developper 
- a sandbox (QA-Integration) to validate the code (SF best practices convention, naming convention,...) 
- a sandbox (UAT) for users tests
- a sandbox (staging) to validate migration to production 
- poduction
What we want to avoid is to take too much time for the prod deployment, found errors in the last step (UAT-staging), found dirty code in another environement than development and we would like to easily roll-back, compare environment, rebase an environment... We think that with the migration tool and svn we can achieve it without encountering too many difficulties but I want to be sure before I implement all the process. So has someone already implemented a similar process in his organization ? Has someone scripts exemple ? If not what do you suggest as a proper process for managing SFDC releases according to our needs ?

Thanks in advance for your answers en your help.

Are there any best practices when it comes to setting up version control (VC) in conjuction with using the Force.com IDE?

For example, should I make one big project in the Force.com IDE that contains all the meta data on my site and commit that?  Then any new classes or triggers should be a part of this project, and committed to VC?  Would this mean that for every feature I deploy, the entire site would be deployed, instead of just the changes I made?  

I'm curious what everyone else is doing.