How to Build a Web Development Environment - 14 Oct 1999

I recently took a consulting assignment at a successful Web hosting company. My customer's company was doubling the number of Web sites it hosted every 4 months, and the Web development group was trying to keep up. When the company implemented its first Microsoft Site Server account, it encountered several major problems, and management realized the company needed to make some changes to continue to grow successfully. These changes included

My assignment was to implement two development servers running IIS 4.0, Site Server, and Microsoft SQL Server 6.5. One server was for Web developers using Microsoft Visual InterDev, and the other server was for developers using Microsoft FrontPage. I had to port a clean version of the current development environment onto each server and develop procedures to streamline development, quality assurance, and Web site publishing in the new environments.

I needed to create an environment in which the Web developers and application developers could collaborate in safety and, in the process, bring order and predictability to the development and production environments. The project had many challenges, and the team (i.e., the customer's Web and content developers and I) learned a lot about how these servers and development tools can work together. Here's how we structured the Web domains and Web sites on the FrontPage development server to set up the development environment.

Problems in the Existing Environment
The company had only one development server, which a production environment administrator administered as needed. The machine had only one IP address. All the development Web sites were in the D:inetpubwwwroot subdirectory and running as sub-Webs of the primary IP domain. The wwwroot home directory contained about a thousand subdirectories and several hundred files. All developers had permissions to wwwroot and could make changes to all Web sites.

During the company's first couple of years, many creative Web authors had developed their clients' Web sites, using a lot of art and sample layouts. By the time I arrived, the system was too big and complicated to be useful. Without checking each file individually, no one could tell which files developers were using. In some cases, entire directories (Web sites) were in question.

To avoid clutter in the development server, some authors had created their Web sites on their notebook computers, publishing finished work directly to production. Other authors were editing Web content directly on the production Web site. Neither of these groups had an up-to-date copy of the Web sites on the development server. Developers weren't testing changes completely, so broken links and missing or orphaned pages were common. If a failure occurred, the only fallback was to the most recent tape backup.

The application developers routinely created new development Web sites using different ports on the primary IP address. The server's Microsoft Management Console (MMC) defined many virtual servers on various ports, but I wasn't sure which developer owned which site or which sites were important enough to keep.

The Plan
The company had decided to use FrontPage to manage and maintain all its content-only Web sites and Visual InterDev to implement Web applications. Because an application development server is subject to outages as developers create and test new applications, the team decided to develop Web content on one machine and applications on another—both on the same intranet. In addition, the team decided to build a production shadow environment as the final integration test site for all new content and applications. The shadow environment was to be as close to the production environment as possible. My consulting company would build the environments, train the administrators, and work with the developers and managers to develop procedures for merging, testing, and publishing applications and Web content.

I was responsible for creating all the servers, setting up all the group and individual permissions, and making sure all the products were working together by the time developers installed the Web applications in the shadow environment. The team developed a plan to migrate the company into the new development environment. The plan had several steps:

Setting Up Domains
The team gave each content developer a Web domain on the server. We used host headers to implement these Web domains. Host headers are an element for identifying Web sites that lets you define multiple Web domains on one IP address. (The sidebar "What Is a Host Header?" explains this element. Also, see my article "Using Host Headers to Set Up a Multihomed Server"—October, 1999—for details on setting up host headers.) The server was running Windows NT 4.0 Service Pack 3 (SP3), NT Option Pack 4, which includes IIS 4.0 and the MMC, and FrontPage 98 server extensions.

First, we added a new IP address to the machine solely for the Web development domain (as I described in last month's article), and we set up the file directories for the development domain. For example, in the structure

D:WebDev   D:WebDevMarniesDomain   D:WebDevVelsDomain

each developer has a directory in the development domain. This directory becomes the developer's primary development Web domain. The individual Web sites that the developer is working on are in subdirectories.

Next, I defined the new primary Web domain, using the new IP address on port 80 and the home directory D:WebDev. You must define a primary Web domain that uses the IP address on port 80 and has no host header before you can define host header domains on that IP address. In this example, the primary domain is WebDev. If you don't set up a primary domain, the new host header domain sends an error message when you try to start it, telling you to check for conflicts in other Web site definitions. Finally, I defined a host header domain for each developer. So each of the Web domains—webdev, marnies_domain, and vels_domain—listens on port 80 of 205.174.179.81, but because each domain has a unique host header (or no host header), each domain receives the requests sent to it. Screen 1 shows the Properties windows I used to define the Marnies Domain host header in the MMC.

Because FrontPage manages this Web domain, or application server, and its sub-Webs, you must also check the FrontPage Web check box on the Home Directory tab, as Screen 2, page 14, shows. This action lets the FrontPage server extensions on the development server add the necessary directories and permissions to the Web site.

Screen 3, page 14, shows all the sites running in the IIS Hudson. This view is one of my favorites in the MMC because it shows me all the IP addresses, host headers, and ports in the machine. You access this view by left-clicking the machine name in the left pane. Notice that the WebDev Server, the Marnies Domain server, and the Vels Domain server all use the same IP address; WebDev doesn't have a host header because it's the primary domain in the group.

In the left pane, notice that the WebDev virtual server has both the MarniesDomain and the VelsDomain subdirectories beneath it. Because of the directory structure's inheritance property, you can reach these two Web sites either by using their host header names (e.g., http://marnies_domain) or by accessing sub-Webs or subdirectories under the WebDev domain (e.g., http://webdev/marnies_domain).

Finding the New Domains
Clients on the network must be able to find their Web sites (domains, in this case) on the server. Therefore, I set up the development domain names on the network so that developers could access them easily. In a large corporate environment, you would probably place the host headers and their IP addresses in DNS. In a small environment, you might not have DNS running. If you're using WINS, WINS recognizes only the machine name as the domain name. When you define host header domains for the server, you need to either run DNS or broadcast a Hosts file with all your domains and IP addresses listed to each client. If you're not using DNS, you need to keep a Hosts file to store the domain names and their IPs.

The Hosts file is a simple text file that contains a list of IP addresses and their corresponding user-friendly domain names. It also contains instructions about how to set up additional hosts. Screen 4 shows an example Hosts file. In Windows, the Hosts file is in the C:windows directory. You can use Notepad to easily edit your Hosts file, but be sure to save the file without any extension—Notepad tries to tack on a .txt extension. My customer's company chose to use a Hosts file because if you put the host header IP entries in DNS, anyone who knows the host header name can access them via the network.

You must set security on each Web site to control access and authorship. You can use the Hosts file as a weak form of security. If you place the Hosts file only in the clients that need to know, such as only in the development machines of the Web authors and developers, you control the distribution of this information and give developers a list of the development Web domains in your environment.

Setting Permissions
After you create the domains and set up and distribute the Hosts file, you must set permissions for the Browse, Author, and Administrative levels of security for each new Web domain. The permissions for a Web domain become the default permissions for any sub-Web created under the domain.

The most common way to set permissions on a Web site is to open Windows Explorer, right-click the Web site directory, select Properties, and go to the Security tab. You can add authors, users, and administrators by clicking Permissions and simply adding the users or groups to the appropriate permissions. For example, to add the NT user marniehutcheson as Author and Administrator to the MarniesDomain Web site, I just select the ID and grant the user Special Access (RWXD), which stands for Read, Write, Execute, and Delete permissions.

Alternatively, you can use FrontPage to set up permissions, according to the following steps:

According to FrontPage, your Web site is a Web server and can have many Web sites. If you created a new site called newweb under the marines_domain Web domain, you could access its pages from your browser by typing the URL http://marnies_domain/newweb. The MMC calls these sub-Webs virtual directories. You can use the MMC to add virtual directories to any domain by selecting New, Virtual Directory in the domain. Or you can use FrontPage to create a new FrontPage site in the domain. These Web sites can have unique permissions for those users who browse the site and those who can author and administer the site.

When the Web site is open in FrontPage, select Tools, Permissions to display the Permissions window with the Users tab active. Click Add to display the Add Users window. This list of users comes from the local NT domain. If you've set up trust relationships on your server, the user list could come from a trusted NT domain. In NT systems, the Web authors must be members of the NT Operators group to use FrontPage on a network.

Select the developer's NT domain user ID and the desired level of permissions (e.g., Administrative, Author, Browse), and click OK. On the Permissions window, click OK to have your changes take effect.

If you want to limit the users who can browse the Web site, you need to create a group or add individual users with Browse permissions. To prevent Anonymous access, select the Groups tab in the Permissions window, and delete the Everyone group.

To let authors create projects and Web sites, I gave the authors Administrative permission in their respective domains. Each Web developer was responsible for publishing his or her projects and client Web sites from their former locations to the new development domain. When the company reassigned a Web site to a different Web developer, the administrator published the site to the new developer's domain and the administrator deleted the old development Web site. Therefore, all the Web sites belonging to a developer appear as sub-Webs under that developer's domain.

A Safe, Efficient System
Using host headers lets you define many domains and sub-Webs on one server. You can make these domains available to internal users by user ID or group or anonymously. You can set special author permissions to give each Web author a private domain. By partitioning the development environment into individually owned domains, you not only make the organization of all the Web sites more manageable and easier to back up but you also establish accountability for individual projects.