Comment Seperate environments, deploy from source control (Score 1) 66
Dev / Testing / Staging-Acceptance-PreProduction / Production
Each developer should get their own virtualhost on the dev server that can mimic production (apache virtualhosts if possible, or use vmware), that they can upload and self-test to. Use wildcard dns for hostnames like username.dev.company.com.
Depending on how many paralell things are tested, you might want more testing systems. Testing boxes should be mirrors of production software-wise (or at least as close as you feel comfortable).
Staging/Preproduction might be optional if you're a small shop or don't need acceptance testing - this should be a more stable place to do system tests outside of the possibly buggy testing environ. again, should mimic production, possibly closer.
production - obvious.
If you can do it, do deployments from SVN via labels or tags (not sure which it uses) like RELEASE_2006-12-27_NOTE (and something like RELEASE_LIVE which moves), so you can track revisions which are on production. Instead of copying code up, you use svn to sync code down, probably through some kickoff script. this occurs to each environment. Take everyone's access away from production, and probably staging - testing you might give select people access. Only the people in charge of the machines themselves, and whoever's in charge of releasing code should have access. Use automation with secure keys and stuff to do deployments.
automated tests happen in testing on a machine that can automatically sync itself to the latest checked in code.
Potentially, all of the above (cept for probably production) could easily be virtual machines.
Each developer should get their own virtualhost on the dev server that can mimic production (apache virtualhosts if possible, or use vmware), that they can upload and self-test to. Use wildcard dns for hostnames like username.dev.company.com.
Depending on how many paralell things are tested, you might want more testing systems. Testing boxes should be mirrors of production software-wise (or at least as close as you feel comfortable).
Staging/Preproduction might be optional if you're a small shop or don't need acceptance testing - this should be a more stable place to do system tests outside of the possibly buggy testing environ. again, should mimic production, possibly closer.
production - obvious.
If you can do it, do deployments from SVN via labels or tags (not sure which it uses) like RELEASE_2006-12-27_NOTE (and something like RELEASE_LIVE which moves), so you can track revisions which are on production. Instead of copying code up, you use svn to sync code down, probably through some kickoff script. this occurs to each environment. Take everyone's access away from production, and probably staging - testing you might give select people access. Only the people in charge of the machines themselves, and whoever's in charge of releasing code should have access. Use automation with secure keys and stuff to do deployments.
automated tests happen in testing on a machine that can automatically sync itself to the latest checked in code.
Potentially, all of the above (cept for probably production) could easily be virtual machines.
