What to know before setting up a new Web Dev Env?

Say you want to create a new environment for a team of developers to build a large website on a LAMP stack.

I am not interested in the knowledge needed for coding the website (php,js,html,css,etc.). This stuff I know.

I am interested in what you need to know to setu开发者_如何学JAVAp a good environment and workflow with test server, production sever, version control, backups, etc.

What would be a good learning path?

---

As someone who has lead this process at several companies, my recommendation is to gradually raise the "maturity" of your organisation as a software factory by incrementally consolidating a set of practices in an order that makes sense to your needs. The order I tend to follow (starting with things that I consider more basic, to the more advanced stuff):

1. Version control - control your sources. I used to work with SVN but I'm gradually migrating my team to Mercurial (I agree to meagar's recommendation for a distributed VCS). A great HG tutorial is in hginit
2. Establish a clear release process, label your releases in VCS, do clean builds in a controlled environment, test and release from these.
3. Defect tracking - be systematic about your bugs and feature requests. I tend to use Trac because it gives me a more or less complete solution for project management plus a wiki that I use as a knowledge base. But you have choices galore (Jira, Bugzilla, etc...)
4. Establish routine Testing practices. Unit tests e.g. by using one of the xUnit frameworks (make it a habit to at least write unit tests for new functions you write and old code you modify) and Integration / System tests (for webapps use some tool like Selenium).
5. Make your tests run frequently, as a part of an automated build process
6. Eventually, write your tests before you code (Test-Driven Development) and strive to increase coverage.
7. Go a step forward in your build/test/release cycle by setting up some continuous integration system (to make sure your build and tests are run regularly, at least nightly). I recently started using Hudson and it is great for our Java/Maven projects, but you can use it for any other build process as well

In terms of testing environments, I agree with meagar's recommendations. We have these layers:

1. Test at developers workstations (should contain a full setup to run your code)
2. Staging environment: clone your production environment as closely as possible and deploy and run your app there. We also use VMs.
3. Production preview: we deploy our app to the production servers with production data but in a different "preview" URL for our internal use only. We run part of our automated Integration tests against this server, and do some additional manual testing with internal users
4. Production - and keep fingers crossed ;)

In terms of backup, at least for your source code, distributed VCS give you the advantage that your full repos are replicated in many machines, thus minimising the risk of data loss (which is much more critical with centralised repos as is the case with SVN).

---

Before you do anything else, ask your developers what they want out of a test/production environment. You shouldn't be making this decision, they should. The answer to this depends entirely on what kind of workflow they're familiar with and what kind of software they'll be developing.

I'd personally recommend a distributed VCS like git or mercurial, local WAMP/LAMP stacks on each developer's workstation (shared "development" servers are silly) and a server running some testing VMs which are duplicates of your production environment. You can't ask for more specific advice than that without involving your developers.