How should we set up a web server that supports ongoing development?

Question

I have rented a VPS (Linux - Fedora) and it's to be used as a web server for both development and production of the same web application.

I have yum-installed apache, subversion, and all packages necessary for running PHP.

In apache, I have created two virtual hosts:

dev.mydomain.com (for ongoing development, /var/domains/dev.mydomain.com/public_html )
www.mydomain.com (for production, /var/domains/www.mydomain.com/public_html )

There will be only one developer and he will use Netbeans as the IDE on Windows XP.

I can imagine that the first thing he will do is to checkout a copy from the SVN repository to his computer in Netbeans. What I am going to do is to just setup two SVN repositories on these folders.

/var/domains/dev.mydomain.com/public_html
/var/domains/www.mydomain.com/public_html

So, when he does some changes on his local copy and then commits the changes, then he can visit dev.mydomain.com on his browser to view the pages and do the code debugging.

Later when he thinks the codes in dev.mydomain.com can be used in production, he can use Netbeans to commit the changes to www.mydomain.com.

Is there any problem with the above scenario? Is this how such a web server should be setup?

Answer 1

Assuming you are doing pure HTML/graphic design, this should be fine. If the sire is dynamic, especially if it is doing anything even vaguely complicated/interesting/tricky, I'd not set up my production box to be my development box.

You want a development environment that is as much like your production environment as possible, and using the same box does accomplish this, but there are a few problems. The most important is that you can bring down your production box testing your new development. Infinite loops, functions with no proper exit, database snafus.... All of these (and more) can negatively impact your production environment.

My first inclination, if you are not doing in-house development, is to rent a second box. My second inclination is to buy a cheap beater box you can replicate the environment on. It is less critical that the hardware be a near match than the software. For example, at my last job, we had high-end small business standalone servers in a colo to handle our production environment. Our test environment was a pair of eMachines.

To recap: if you are doing any dynamic web development, I'd not use production to test it. Get a second hosted environment, or buy a beater box and set it up identically.

Answer 2

It's handy to be able to commit and publish automatically at least for small projects, but a real deployment script (e.g. using rsync as @Kevin M suggests) provides better control and isolation of the production environment. For instance, some frameworks depend on a certain directory setup (for caches, tmp dirs) that it doesn't make sense to keep in subversion. A deployment script can make sure these directories exist have the proper permissions, etc.

You'll need to do a couple things if you want commits automatically published:

1. This article describes how to set up automatic deployment on commits. You may or may not need all of the scripts depending on user setup, permissions, etc.
2. You'll want to make sure your server is configured to not serve up the .svn directories in your published working copy.

Also, if you're depending on installed software (php, python, etc). You'll want to come up with a plan for how to perform upgrades and test them in dev before pushing the software to production. This is harder to do on a single box.

Answer 3

I think that the repository information is stored in the working copy, so it won't commit to just any place specified. Also, the information is stored in a database format, not in the familiar directory/directory/directory/file.html folder structure that it's stored on for the client.

What you want is rsync. The developer will do his normal svn checkout from the subversion repo like you outlined, but then when he's ready to push to production, either you or he will log onto the server via ssh and do rsync -av --cvs-exclude /var/domains/dev.mydomain.com/public_html /var/domains/www.mydomain.com/public_html. This list everything that has been updated and at the same time copies to production, except for the .svn directories