I am setting up some servers for website development. I want it to be organized in a fairly standard way. How do you organize your servers for development of relatively small websites, each with a little bit of unique code?
Some details I am concerned about include (but not limited to):
What distinct servers exist with respect to the development process? What is their purpose?
Where is your master source repository?
Where is development work done?
Where is testing done?
What distinct servers exist with respect to the development process? What is their purpose?
Where is your master source repository?
Usually internal access only, can share this machine with another purpose e.g. CI.
Where is development work done?
On each developers local machine is best, then integrate changes via SCM and CI.
Where is testing done?
Usually on a server set aside for testing. Normally there is a set of environments and builds are promoted through each stage as they pass testing:
At work we occasionally have two people working on the same site so it goes something like this:
Every site is in source control (Microsoft Source Safe) and we work with and test local copies on our own computers most of the time. Luckily Visual Studio 2008 makes this easy with its built-in web server.
When we want to test in-house with multiple users, we deploy to our in-house development server. (We will always do this before deploying to production.)
When we want some outside hired consultants to review the site before going to production we might deploy to our production server but with a special host header separating it from the live site, e.g. staging.yourdomain.com (This step is often skipped).
As a last step we deploy to the production server at the data center.
I've tried variations of this over the years. But doing it this way requires only 2 physical servers and the developer's workstation. And yet it's structured enough that it's been a dependable process for us.
1) What distinct servers exist with respect to the development process? What is their purpose?
In my experience, the only concept/idea that should matter is that all the environments (servers => development, staging, production) should be if not exactly alike, similar with regards to OS, web server versions, service packs, patches, hotfixes, etc. Now, it may or may not be feasible to have a minimum of 3 (or more) distinct environments, but this tends be the norm from my experience. In terms of hardware, as long as their very similar or identical it shouldn't pose any problems down the road.
2) Where is your master source repository?
Isolated from internet access and heavily guarded. Lots of firewall rules to protect it from undesirable attempts at gaining access. Only developers in-house should be able to access the repository.
3) Where is development work done?
In larger projects or in organizations, development tends to be done locally on a programmer's computer or with the aid of source repositories (SVN,CVS,VSS,etc.) a copy of the work is done locally.
4) Where is testing done?
Some people test in their "development" environment, others do testing in "staging" which to me makes a little more sense. Pick one of the two and just stick with it. Personally, I think staging is the place to test to avoid version changes if developers are making changes to development.
How do you organize your servers for development of relatively small websites, each with a little bit of unique code?
Basically, web shops organize their environments as: development=>dev, staging=>stage, production=>prod. Developers work locally on their own machine, and once their additions/changes are finished they commit the changes to the source repository. Certain shops do something called CI (continuous integration) so after every commit a developer makes, the CI server automatically rebuilds to the site. This helps developers/testers to see if anything broke from a developers changes.
Typically these changes are published to their dev environment for all developers to work with. When the developers get to a certain milestone/checkpoint and want to start testing they "promote" the version of their site to staging environment for testers to hammer away at while developers can continue to work in dev.
Once everyone is content with everything in staging, they promote the version in staging to prod. Changes should only flow one way: dev->stage->prod. If you want to make a change to production, start from dev then test in staging and then promote to production. It's a pain but it keeps things consistent and prevents from numerous headaches. You'd be amazed how many companies just make changes in production and months/years later they're having problems syncing environments when just following protocol would've saved them a lot of pain.
If you're referring to your work as "small" as in simple or not complex beyond some dynamic pages and some database calls, I'd say try to go for 3 environments but you could probably "get away with" 2 environments (staging and production). You could make your own computer the so-called development environment.