phpsvnbranchcollaborationbranching-strategy

Multi-Developer-Setup with SVN-VC and remote test-servers for each developer. Best practices?

I would like to have some input on how a professional development setup with the following requirements might look like.

I gave some specific technology to not be too abstract and b/c I also would be interested in concrete suggestions for plug-ins etc.

There are several questions coming to my mind in that setup.

1) So every developer will work on personal branch.

2) This branch is checked out in a working copy.

Now ... this working copy is edited locally on the PC with the dev's IDE and executed/tested on the server.

What would be in that case the best/usual way to do that? I mean - how do you get your edited code on the server without causing too much overhead?

Would the dev have the code on his local disk at all? Or would it be better to have the IDE write on the remote virtual server through a tunnel or via a specific protocol?

3) Every day a dev will commit his work into his personal branch which resides in a central repository.

Is there a best practice on where the repository is supposed to be located? A seperate server?

4) Then after a dev finished his task either s/he or the team-leader merges the new code into the respective main-branch or trunk.

The most confusing part is about what I wrote between 2) and 3). Because so far I only worked with a local server. For example a VM with a server running a code which is located in a shared folder so I will be able to edit it directly. I'm not sure how to bridge the gap efficiently when the server is now actually remote. Efficiently means not having to upload manually via FTP for example.

Also external sources or book recommendations are welcome.

edit

My question/s is/are aiming at a quasi-standard / best-practice. I think this is pretty much a standard development scenario so there must be a 'usual' solution.

edit 2

Okay ... so lets try with a picture: the setup

V is the virtual test-server for one or more developers D. C and C' are the two code-versions. They should be kept as identical as possible.

Two solutions come to my mind:

1 : Edit C, then upload it to C', then execute C', then commit C.

2 : No C existant. Just C' which is edited through some tunnel technology and executed and committed.

My guts tell me both solutions are semi-optimal. So what would be "professional" / most efficient / fastest / most convenient / most friction-less / least error-prone / best practice / industry standard?

Any questions?

Solution

  • I'm sure everyone has different ways of doing things but here are my thoughts.

    "Best Practice" is probably "Continous Integration" ie each developer doesn't have their own branch but checks in to a common development branch. This forces them to handle conflicts and coordinate with each other early and often to avoid the lead developer from managing a huge train wreck merge later down the road. Take a look at cruisecontrol if you really want to go that route.

    The best way is if they have a local apache web server and full php stack. You can use the Zend_Server community edition to get up and running on windows fast. Most standard php code will run just fine on both Windows and Linux, but if you are doing lots of file manipulation or cron job or cli stuff, or need memecache, etc you'll run into incompatabilities. If thats the case and the Linux only stuff is going to bite you use VMWARE or VirtualBox to run local linux instances and install the IDE inside those and just make sure they have goobs of RAM to deal with it.

    Each developer needs to run a syncronize inside of Eclipse, basically an svn update, deal with any conflicts with the other developers right then and there, do local testing and commit their changes.

    I setup a post_commit hook on the svn server that calls and /autobuild.php on my web server. autobuild.php runs svn update and gets the latest code changes as well as does any chown or chmod file permissions stuff and resets any server specific config files config.php. Its a little tricky to get it setup so that the apache user can run svn update, but once you do your beta/testing server always has the latest committed code. CruseControl, and several others can also help you do this sort of thing and add unit testing, etc

    Now your Lead Developer still has a job to do merging the Development Branch into the Production One, testing on the dev server, and reviewing the commits of the others and deciding how and when to push out a release, but your not putting the burden on him of resolving every conflict and merging every change.

    Your developers are not ftping files or ssh remoting into servers, they just work locally in their IDE and interact with each other through svn (and email, phone, chat, etc) updating to get the new code and commiting as they finish things.

    I don't see any good coming out of having a seperate branch for each developer using SVN. Merging those branches might work in Git but with SVN your lead developer will be hating life very quickly with that type of setup.