Development Environment
Aug. 12th, 2008 11:52 amSo tomorrow we're having a meeting to discuss the development environment that we're going to use for an upcoming project. This has kept me somewhat busy thinking about it, but I'm reasonably sure I know what we need.
First, hardware. I'm going to be proposing that we buy a new server. A big, beefy server that can run up to three VM instances on it. Those three VM instances will be our development environment web server, our development environment database server, and a development server running a couple of other things. If we can't get one that will run three instances, than we'll get one that can run two instances and another, smaller one, for our development server
The development environment web server and db server are boring. IIS and SQL Server 2005. Yawn.
The development server is the really interesting thing - in one fell swoop I'm proposing updating a lot of our development practices:
First, hardware. I'm going to be proposing that we buy a new server. A big, beefy server that can run up to three VM instances on it. Those three VM instances will be our development environment web server, our development environment database server, and a development server running a couple of other things. If we can't get one that will run three instances, than we'll get one that can run two instances and another, smaller one, for our development server
The development environment web server and db server are boring. IIS and SQL Server 2005. Yawn.
The development server is the really interesting thing - in one fell swoop I'm proposing updating a lot of our development practices:
- Install Subversion as our source control client. This is head and shoulders above Visual SourceSafe, and represents a new model of source control that makes multiple people editing a file easier and makes it a lot easier to branch off the main development trunk. This will involve installing TortoiseSVN and AnkhSVN on developer boxes.
- Cruise Control.NET. This is iffiest - I'm not sure I can get support for true continuous integration.
- nAnt. If I can't get support for continuous integration, I'll need this anyways. Minimally, we're going to do nightly builds. They're the best way to determine that progress is being made and that quality is being maintained during the code construction phase of a project.
- fxCop. This allows us to do code construction checking based on a set of rules generated by Microsoft guidelines. We'll be taking a close look to turn off rules that are stupid.
In addition, we'll be upgrading to Visual Studio 2008 as soon as possible . I believe the plan is to get the MSDN SKU of it, which will be awesome. We'll also be creating a seperate area of FogBugz for the use of this project and discussion best practices for using that.
Getting all this through will probably be a not easy task. But doing it will get us right on line for some world-class development environment characteristics. And it will make our projects more successful - which means it will be worth it.