* What do I need to make this happen?
* What approaches do you use for team based web development?
* How many servers do you have?
* Can all of these run on the same server?
* What other pitfalls should I watch out for?
I'm a big fan of the Microsoft tools, in part because they're well integrated with each other. Subversion may not cost anything to buy, but that doesn't mean it's free: you still have to pay your team while they learn, use and maintain it, and to fix any problems that might come up along the way. In my experience, software costs tend to be small when you take the long-term view.
Without knowing anything about your team, your product, your budget, your software process, and many other factors that should be folded into a decision like this, I can offer the following very general recommendations:
- Use Visual Studio Team Edition for your development. Team Test provides load test capabilities. Team Data provides database versioning and automated deployment and update, as well as data generation and database unit testing. Team Developer provides mechanisms for unit testing web apps, plus profiling and static code analysis. Team Suite provides all features in one package.
- Use Team Foundation Server for source control; it includes automated builds, a SharePoint-based team portal, transactional check-ins, full integration with Visual Studio, integrated bug reporting, uses SQL Server as the repository, provides team-oriented statistics (bugs per day, etc), facilitates hand-off of test data from QA to Devs, etc.
- For hardware, get one dedicated server for TFS and builds. Use a Windows domain, and have a separate server as the domain controller and for misc storage and to hold backups from the TFS server (Exchange might run there, too). Each dev has their own machine, including enough resources to run a local copy of SQL Developer, assuming your app uses a database. Gigabit networks connecting everything.
- For larger apps or teams, it's also a good idea to have an internal test environment of one or more servers that's configured somewhat similarly to your production servers, in terms of things like separate volumes for DB data and logs, load balancing / web garden, etc. Nightly builds get deployed there, for testing the next day. That can be one server, or in some environments, possibly a virtual server.
- Automated deployment gets more important the larger your project becomes. There are some cool options there in multi-server environments, such as Windows Deployment Services (WDS).
- Don't forget about monitoring and logging.
In case it's helpful, I cover a number of these issues and options in the Infrastructure and Operations section of my book: Ultra-Fast ASP.NET.