It doesn't matter which DVCS you use, particularly since you haven't mentioned using CVS (thank god). Use whatever the designers will actually use. If they're already comfortable with SVN use SVN; the git-svn integration tools are not as great as an all-git setup, but I've been using them with great happiness. And there are quite a few competing GUI clients for SVN.
Pay Devguard or github or somebody to host your VCS. Don't waste your client's money setting it up yourself.
Given this sentence:
Unscheduled downtime of more than a couple minutes is unacceptable any time.
My first instinct would be to try and get the production server mirrored to a nigh-identical second box that you can, in a pinch, fail over to. Once you know how to do that you can clone one or the other of these redundant production servers to a staging server and test your new code on that.
For all of those tasks you use boxes that resemble your production box -- same Unix version, PHP4, MySQL 4. Slicehost VPS instances are cheap. Rental servers are cheap. But trying to get your motley collection of Macs and PCs to accurately simulate your deployment environment may cost a lot of time.
You can use your local machines for development if you want, then upload the results to the staging server for testing, but even that might be a big time sink, depending on the nature of your app. I've been working that way, but I've now been bitten more than once by bugs that are caused by slight differences in versions or modules between my Mac's PHP/MySQL setup and that on the production servers. I've begun to wonder whether it might be better to just get each developer a remote development VPS (or a directory on a shared development VPS), install identical clones of the development code and the database for each developer, and have everyone develop over a SSH connection, and/or via an intelligent sFTP client like Transmit for the Mac. This, I'm told, is how Flickr develops new code -- their production environment has too many moving parts to be worth simulating on a single local machine. But, of course, I'm an emacs user so the thought of editing files over SSH isn't that horrifying.
If you're going to be tinkering with mission-critical code that costs $N per minute every time you introduce a bug, you may need to move the writing of tests up in the calendar.
Don't forget the bug tracking! I'm not in love with Trac but it gets the job done -- again, pay somebody like Devguard to host it for you; don't waste time setting it up yourself. Or try Lighthouse or something else if you don't like Trac. Try out Basecamp.
Hey MR FISH I never got the chance to thank you earlier, this really is a useful comment. The first thing I did after reading it was set up a stage and god I am so much more relaxed during deployment.
Bug tracking etc fall into place in about 2 weeks. Still some API integration to do and a n00b to onboard ... :)
Pay Devguard or github or somebody to host your VCS. Don't waste your client's money setting it up yourself.
Given this sentence:
Unscheduled downtime of more than a couple minutes is unacceptable any time.
My first instinct would be to try and get the production server mirrored to a nigh-identical second box that you can, in a pinch, fail over to. Once you know how to do that you can clone one or the other of these redundant production servers to a staging server and test your new code on that.
For all of those tasks you use boxes that resemble your production box -- same Unix version, PHP4, MySQL 4. Slicehost VPS instances are cheap. Rental servers are cheap. But trying to get your motley collection of Macs and PCs to accurately simulate your deployment environment may cost a lot of time.
You can use your local machines for development if you want, then upload the results to the staging server for testing, but even that might be a big time sink, depending on the nature of your app. I've been working that way, but I've now been bitten more than once by bugs that are caused by slight differences in versions or modules between my Mac's PHP/MySQL setup and that on the production servers. I've begun to wonder whether it might be better to just get each developer a remote development VPS (or a directory on a shared development VPS), install identical clones of the development code and the database for each developer, and have everyone develop over a SSH connection, and/or via an intelligent sFTP client like Transmit for the Mac. This, I'm told, is how Flickr develops new code -- their production environment has too many moving parts to be worth simulating on a single local machine. But, of course, I'm an emacs user so the thought of editing files over SSH isn't that horrifying.
If you're going to be tinkering with mission-critical code that costs $N per minute every time you introduce a bug, you may need to move the writing of tests up in the calendar.
Don't forget the bug tracking! I'm not in love with Trac but it gets the job done -- again, pay somebody like Devguard to host it for you; don't waste time setting it up yourself. Or try Lighthouse or something else if you don't like Trac. Try out Basecamp.