Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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):

  1. What distinct servers exist with respect to the development process? What is their purpose?

  2. Where is your master source repository?

  3. Where is development work done?


locked by HopelessN00b Jan 21 '15 at 9:13

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as primarily opinion-based by HopelessN00b Jan 21 '15 at 9:13

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

  1. I recommend the following infrastructure:
    1. Development master server, containing source control, bug tracking, run the build VM, etc etc
    2. Beefy developer/QA workstations (or laptops, if desired) to act as desktops and to run developer test VMs
    3. Test VMs on each developer's machine, that mirror production OS/configuration, that they can play with (to validate ideas about config changes that might be needed) and can blow away and restore to a known state (from master images) if required;
    4. Test/QA VMs on QA department workstations, so that individual testers can manage their own testing/QA process without stepping on anyone else's toes;
    5. A build/CI VM, where "known good" builds can be produced for internal testing;
    6. A staging environment, which mirrors production in every possible respect, which is used to validate complete builds in preparation for production release, and also to verify changes in the system setup;
    7. Production, which is locked down from developer access, and which is where all the Real Work happens (obviously)
    8. There's also a pile of sysadmin support services, like the gold server that aren't directly developer-applicable.
  2. On the development master server
  3. On developer workstations, either directly (in whatever environment they feel most productive), or in their personal test VMs.

All this sounds like overkill if all you're doing is producing "relatively small websites, each with a little bit of unique code". It sounds like you're a one-man band, in which case stick it all on your laptop (with good near-line and offsite backups) in VMs as appropriate. More importantly you'll want to think about how you structure your code into reusable modules, and how you use your revision control system's branching capabilities to allow the common code to be common, and the unique code to stay unique and not interfere with each other. But that's a question best asked on Stack Overflow, not here.


Not the answer you're looking for? Browse other questions tagged or ask your own question.