How do you deploy a website to your webservers?

Question

At my company we have a group of 8 web developers for our business web site (entirely written in PHP, but that shouldn't matter). Everyone in the group is working on different projects at the same time and whenever they're done with their task, they immediately deploy it (cause business is moving fast these days).

Currently the development happens on one shared server with all developers working on the same code base (using RCS to "lock" files away from others). When deployment is due, the changed files are copied over to a "staging" server and then a sync script uploads the files to our main webserver from where it is distributed over to the other 9 servers.

Quite happily, the web dev team asked us for help in order to improve the process (after us complaining for a while) and now our idea for setting up their dev environment is as follows:

• A dev server with virtual directories, so that everybody has their own codebase,
• SVN (or any other VCS) to keep track of changes
• a central server for testing holding the latest checked in code

The question is now: How do we manage to deploy the changed files on to the server without accidentaly uploading bugs from other projects? My first idea was to simply export the latest revision from the repository, but that would not give full control over the files.

How do you manage such a situation? What kind of deployment scripts do you have in action?

(As a special challenge: the website has organically grown over the last 10 years, so the projects are not split up in small chunks, but files for one specific feature are spread all over the directory tree.)

Answer 1

You need to look at:

• Continuous Integration
• Running unit tests on check-in of code to check it is bug free
• Potentially rejecting code if it contains a bug
• Having nightly builds
• Releasing only the last build that was bug free

You may not get to a perfect solution, especially not at first, but the more you use your chosen solution, the more comfortable everyone will get and be able to make suggestions on improving it.

Answer 2

We check for the stability with ant, every night. And use ant script to deploy. It is very easy to configure and use.

Answer 3

Cassy - you obviously have a long way to go before you'll get your source code management entirely in order, but it sounds like you are on your way!

Having individual sandboxes will definitely help on things. Next then make sure that the website is ALWAYS just a clean checkout of a particular revision, tag or branch from subversion.

We use git, but we have a similar setup. We tag a particular version with a version number (in git we also get to add a description to the tag; good for release notes!) and then we have a script that anyone with access to "do a release" can run that takes two parameters -- which system is going to be updated (the datacenter and if we're updating the test or the production server) and then the version number (the tag).

The script uses sudo to then run the release script in a shared account. It does a checkout of the relevant version, minimizes javascript and CSS[1], pushes the code to the relevant servers for the environment and then restarts what needs to be restarted. The last line of the release script connects to one of the webservers and tails the error log.

On our websites we include an html comment at the bottom of each page with the current server name and the version -- makes it easy to see "What's running right now?"

[1] and a bunch of other housekeeping tasks like that...

Answer 4

You can probably use Capistrano even though is more for ruby there are some articles that describe how to use it for PHP

I think Phing can be use with CVS but not with SVN (at least that what I last read)

There are also some project around that mimic Capistrano but written in PHP.

Otherwise there is also a custom made solution :

1. tag files you want to deploy.
2. checkout files using the tag in a
   specific directory
3. symlink the directory to the current document root (easy to rollback to the previous version)

Answer 5

You should consider using branching and merging for individual projects (on the same codebase), if they make huge changes to the shared codebase.

we usually have a local dev enviroment for testing (meaning, webserver locally) for testing the uncommited code (you don't want to commit non functioning code at all), but that dev enviroment could even be on a separeate server using shared folders.

however, committed code, should be deployed to a staging server for testing before putting it in production.

Answer 6

I gave a similar answer yesterday to another question. Basically you can work in branches and integrate before going live.

The biggest thing you will have to get your head round is that you are dealing with changes to files, rather than individual files. Once you have branches there isn't really a current version there are just versions with different changes in.

Answer 7

Naturally check out SVN for the repository, Trac to track things, and Apache Ant to deploy.

The basic process is managing in Subversion, tracking the repositroy and developers in Trac and using Ant deployment scripts to push your site out with the settings needed. Ant allows you to easily deploy a project to a specific location. (Dev/test/prod) etc.

Answer 8

I'm reading this post with interest because we (4 people... sometimes 5 or 6) use Sourcegear's Vault (and a very outdated version of it at that) for development and testing and then we ftp everything to production.

Weak. I know. Vault is fine if you are using Windows but I work on a Mac and am forced to use it from the command line which cuts out all of the most useful features that the Windows only GUI client offers. I wish we used subversion or git or mercurial or anything else that is decent (all of which I prefer and all of which would offer so much more power from the command line) but it's not my call. Then I wish we had some "real" deployment solution aside from "FTP these files onto the production server and take it for a spin... see if you find any problems".

I look forward to seeing what sorts of real world, non-cludgy, solutions people post here.