Single test server and svn for web development_问答_开发者

I'm a bit confused about proper usage of svn in case of a single test server for web development.

We are trying to avoid creating a l开发者_JAVA技巧ocal test server for each developer, as the system is rather complex and thus difficult to configure and heavy to run. So we are thinking about using a single test server instead, where all the developers (only a few at the same time, actually) could test their changes.

Assuming that we use svn for versioning, how should we proceed? We have considered these options:

All modifications pass through svn. When I want to modify a file, I change a local copy and them commit. However, as I can't do any local tests, we will often have broken code and reverted changes in svn. How bad is that?
The modifications are done directly on the test server, tested, and only then committed to svn. In this case we loose the advantage of local copies / merge, and might thus have problems with several developers modifying the same file...
Modifications are done in multiple "local" copies of the code on the server, and we can switch from one copy to another or run them simultaneously to do testing. This would require a special configuration and lots of space on the server.

Is there a better option that we are missing, or which one is the least worst? Thanks.

How complicated is the environment that changes can't be tested locally? If the environment is too big and complex to run on a developer's workstation, you really want to look into mocking and unit testing. You really have two opposing forces here:

Every code change is so integrated that it requires a full end-to-end test to validate.
Developers can't have an end-to-end environment.

Unit testing (which, of course, requires that code be written/maintained in discrete testable units) and mocking isn't the be-all end-all answer to this problem, but it will help. A lot.

If you go with your first option, continuous integration and continuous deployment to your test environment are critical. Bugs need to be identified immediately or your developers will be creating bugs upon bugs and the whole system will get messy fast.

Your second option is a no-go. If you have an uncontrolled step between the developers and the source control then you entirely undermine the "control" part of the source control. Might as well just store code on an FTP share.

The third option is probably your best bet. Going with that option opens the door for future improvement as well. After all, if you can isolate and essentially rubber-stamp new instances/environments for each developer, then it should be a short distance from there to local environments for each developer. Hardware is cheap, dependencies can be mocked, etc.

Branches might be useful to look in to (http://svnbook.red-bean.com/en/1.1/ch04.html). You could create a branch for each developer, and they could push to trunk when they determine their changes are not detrimental.

If space wasn't a problem, I'd suggest using multiple svn copies on the same server. Have your main directory which you svn update whenever you reach a milestone, and then have several dev folders which are your working copies.

If space is too much of an issue, you really have no other choice than to work directly on the live code, or run it on personal machines.

You sound like you might benefit from better development environments. I understand that a full test system on each developer machine can be heavy, however good unit testing on the developer machines should be done prior to checking code in.

You would benefit from Continuous Integration. Your test environment can become your integration environment where full end to end testing can be done and testing of integration can occur as well. Your test environment should be updated with a fresh deploy daily on the latest code in the working branch.

First approach will kill you in the long run. If you had only one developer making changes and then rolling them back, that would be fine. But having several developers inducing heisenbugs upon each onther. And then comes rolling back changes... Shrug.

If you really cannot afford each dev to have his own local copy of a system to play with, I'd gave your third option a go. Have a separate "instance" of an app for each developer on a beefy test server.

As a sidenote: maybe virtual machines could help you here?

Since your system is sufficiently complex to set up, I would give each developer a "sandbox" on the central testing server, +1 more for "stable" that they all merge into once they are done.

I would also add that the cost of fixing extra bugs and problems caused by working on 1 copy of the code is far greater than the cost of additional server space (in almost all cases). Do your devs a favor and give them each a sandbox of some sort to play in. Your bottom line, in the long run, will thank you, and you will have happier devs.