Companies with a small number of developers working on simple applications consume more overhead than necessary on configuring development workstations and an integrated development environment. Unfortunately, most companies start “small and simple” and expect their development environment to somehow magically scale to support robust development efforts. Sadly, this is not the case. Careful planning is necessary to ensure a productive environment.
System architects must take an active role in planning the configuration and management of the environment used to develop software. Their efforts have a direct bearing on the developer’s ability to produce quality software in a timely manner. More importantly, a development process with a focus on code management provides the benefits of reusability and an opportunity to protect the company’s core code assets. Let’s look at the three key elements of every .NET development environment—development workstations, development servers, and development procedures.
For .NET developers, all workstations should be running Windows 2000 Professional or Windows XP. I recommend that my clients give their developers machines with at least 1.0-GHZ Pentium III processors and 256 MB of RAM. This is faster than the average developer’s machine, but not state of the art. Most developers would benefit more from having a laptop and/or an additional monitor than from additional processors or memory. Laptops allow developers to work together in groups during design meetings or take the machines home at night to work on a difficult problem. An additional monitor lets them write code on one monitor while viewing the help system on another, or step through code on one monitor while seeing the result of the executing code on another. The ideal development environment for .NET requires machines with slightly more RAM, processor cycles, and disk space than the average workstation.
Developers working on Web applications or Web services must have a local Web server for use during development. In addition, the Microsoft Database Engine (MSDE) should be running to allow developers to build and test via local databases, stored procedures, triggers, and so on. MSDE includes all of the functionality of the more resource-intensive SQL Server 2000 Workstation, but it has no licensing cost and limits performance with more than five connections.
In many corporate environments, all data access is managed by centrally developed and maintained stored procedures called from data objects coded by database-focused developers. In these environments, the data-component authors should be encouraged to develop deployment packages that allow developers to download the latest versions of the components and setup scripts and set them up on their own local workstations. Install Visual Studio on each of the workstations, but consider installing MSDN on a central server where it can be updated in one place as new files are added (unless the workstations are laptops, in which case they’ll need local copies to allow access to help when disconnected). If you need to support applications running on Visual Studio 6.0, ensure VS 6 is installed with the latest service pack (version 5) before installing Visual Studio .NET. Finally, install the latest service packs for all of the workstation tools, including .NET Framework service packs, SQL Server service packs, and IIS service packs.
Even if your individual workstations are configured to allow developers to create and test their projects locally, you must have a central location for developers to test the interactions between system components. At a minimum you need a shared Web server, a shared database server, and a source code management/build server with Visual Source Safe (VSS) or another source code management system. Ideally, the workstations and the shared development servers will exist in test domains similar to the deployment environment. If the deployment environment is a single domain, place the development servers in a development domain that is separate from the company’s core operational domain. This allows for user- and group-accounts creation to test security scenarios without needing to clear it with the company’s system engineering group. If a datacenter has database servers and Web servers in different domains for security reasons, you can simulate this environment with local development servers. The earlier you test against a development environment that simulates the production environment, the earlier you can detect and repair security-related bugs.
Creating the right development environment is only half the battle, however. You must have agreed-upon development standards for all developers to follow. For example, developers should be trained to use the source code management system and be expected to follow the rules for checking software in and out and for managing software versions. Once past the prototyping phase, the code your developers check in at the end of a workday should compile properly and facilitate building a version of the software every night. Having a nightly build procedure encourages developers to focus on tying up all the loose ends in a section of code before moving on to work on something else. The shared VSS and build server can be configured to automatically perform the nightly build and distribute the latest version of the code to the quality assurance group so that they can start working with the latest build the next morning.