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

Question

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

• several PHP-developers (say PHP)
• each developer belongs to one group
• each group has one team-leader who delegates tasks
• each developer works on one Windows 7 machine
• and developes either with NetBeans or Eclipse
• each developer 'owns' one virtual test-server where he can run the code
• the VCS in use is SVN
• there is a staging server where the product is ultimately tested before it gets released/deployed

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:

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?

Answer 1

Maybe its not of great help but GIT sounds like a perfect fit to your problems, i recommend to take a look to the GIT features. And if you got time check Linus Torvalds him self talking ablout GIT. http://www.youtube.com/watch?v=4XpnKHJAok8

Answer 2

The standard procedure as you describe is more or less the same. I also you this approach for my team. It can also be called staged application development.

Here is how I am doing it, I use a remote SVN host (ex: assembla.com, unfuddle.com) to store all my codes. My team members store the information there on these remote svn servers. You can also buy an VPS and setup SVN there and user the same approach.

Best practices is to test locally and commit and commit as many times as you can but every commit must solve a problem or include a significant segment that adds any new feature.

Once the commit is done by everyone the lead developer then can login to the staging server via SSH using tools like PuTTY. First time the lead developer has to checkout the code into the folder where the codes are to be located. During this phase file conflict may arise if multiple developers edits same segment of a file. The lead developer should then resolve the code first and then proceed with the checkout. Once checked out, there onwards the lead developer will only need to do a svn update on the staging server to make the code up to date.

Basic idea is to get the code working on local setup then commit and update the staging for testing the application on a simulated scenario and then commit it to the live site.

There are a lot of if's and but's here which will need me to write a chapter on :) but in short this is the zest.

Tools (you can use to work under this setup): - Tortoise SVN Manager - PuTTy - NetBeans

hope it helps :)

Answer 3

I don't like working with personal branches. I worked with ClearCase for almost 15 years and even though ClearCase probably handles personal branching better than most, it was still a big pain. Even worse, personal branches encourages people to not commit their work until the last minute -- usually a day or two before a major release.

For that reason, and to force developers to stay on track with each other, I highly recommend everyone working together on a single branch (or on the trunk) as much as possible. I keep telling developers to take small bites when they make changes.

What you sound like you need is a way to automate the deployment. That is, I make changes on my local machine, and with a single command, I make sure that the server has a duplicate copy of the code. You also want the deployment to be efficient. If you change a single 2 kilobyte file of a 2 gigabyte, 10,000 file deployment, you only want to copy over that one file, not 10,000 gigabytes. For that, I would recommend you write a deployment script in Ant.

Your developers can modify files, then deploy those files via an Ant script. The developers don't have to remember what files they had updated because Ant will automatically handle that. In fact, Ant can even modify files to make sure they contain the right environment information as they get copied over. And, of course, Ant can rearrange the files if the setup on the server is different from the setup in the source repository. And both Netbeans and Eclipse can execute Ant scripts right in the IDE.

So:

• Have your developers modify code on their local machine.
• Run an Ant script to make sure the server and the local machine are in sync.
• Test on the server.
• Then, check in their changes once they're happy with the results on the server.

Someone mentioned a Continuous Build System like Jenkins. That actually would be a good idea anyway even though it doesn't solve this particular issue. Jenkins could have its own server and database. Then when you commit your code, Jenkins would update the server and run automated tests. Jenkins can then create a report. It all gets displayed on Jenkin's webpage. Plus, you can archive your deployments on Jenkins, so if you tell someone to test "Build #20", they can simply pull it off of Jenkins where its easy to find.