CODEWITHSUNDEEP
.netasp.net
Daniel Lang
Daniel Lang

Reputation: 6839

Specifications for Servers for Team Based Development

Background

My business is getting more and more requests for web development and as such I'm adding another .NET Developer to the team.

My current development environment is really poor, just a single PC (Windows XP) with a local IIS installation hosting web development projects. I open those with Visual Studio 2008 Professional, with no version control in use.

Problems with this Approach

This approach doesn't fit any requirements of team based development and hinders Test Driven Development, Versioning and Deploying. Because of this, I plan to install a domain environment with Windows Server 2008 and an additional Web server devoted to development.

Business Requirements

Questions

Upvotes: 1

Views: 639

Answers (3)

RickNZ
RickNZ

Reputation: 18654

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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.

Upvotes: 0

Neil N
Neil N

Reputation: 25258

  1. Get a version control system in place. Subversion with tortoise (and Ankh addin for VS) is nice and free.
  2. You dont need a dev server, have both developers run locally from thier checked out repos.

Upvotes: 1

Justin Niessner
Justin Niessner

Reputation: 245409

First, set up some sort of revision control for your source code (Subversion is free).

Then, each member of the team gets a local development environment (SQL Server, Visual Studio, IIS if needed). They each have a local copy of the Source Code and Database. They make and test changes here.

Once changes are tested locally, they get commited back to the source code repository.

If you have another spare server sitting around, you could push a nightly build of the application from Subversion to that server to test the builds being made. Part of that build could be to run any Unit tests you have (even though developers should be running them locally as well) to make sure the build doesn't fail.

Upvotes: 4

Related Questions