It is a common practice in many firms to create separate environments within their infrastructure. Essentially, an environment is the collection of hardware, software, and staff to support your site at a given stage in the development cycle. The reason for this separation is to allow each environment to satisfy the needs of a specific audience or application without affecting any other. For example, a development environment would contain the hardware, software, and staff to support your developers and the creation or modification of functionality within your CMS-based Web application. This development environment typically has very early versions of code and/or components that are likely to be unstable or ill suited for a public or semipublic application. Since the hardware and software components in this environment are constantly changing, potentially breaking some features or functions while fixing others, the development environment is the domain of the development staff only.
In this section we'll discuss various environments you may consider implementing as part of a typical deployment. One deployment could be made up of one or more environments discussed here.
Overall, your particular deployment strategy will be unique to your organization. In addition, a deployment may be different based on the audience that will be using the application. However, there are some basic guidelines that can be used in various forms to create an overall deployment strategy for your CMS application.
In this section we'll briefly describe and show different environment types as they relate to CMS. Later, when we talk about specific deployment scenarios, we'll reference these environments to build a particular deployment.
The most basic environment is a development environment. The development environment, as discussed earlier, is where your developers will primarily work. This environment is made up of a central server and all the development workstations your developers will be using. The central development server will run a copy of CMS and SQL. Both tools can be loaded on one physical box or they can be separate; the choice is up to you. This central CMS server will hold the "master" copy of all the templates and controls that make up your application. Because it's not possible to perform "remote" development on CMS (i.e., you can't remotely connect to a CMS server using VS.NET), each developer workstation will have its own copy of CMS, along with VS.NET. Each of the developer workstations will then connect to the central SQL server so that they can share TGIs and postings. In this environment, each developer can develop their component of the application on their individual workstation. Once they're done, they either copy the component to the central server or simply check it in to the source control utility of their choice. The development environment will likely be configured to use Windows authentication and have guest access disabled. Figure 22-1 shows a logical diagram of what this environment might be like.
Figure 22-1. A CMS development environment
Depending on the complexity of your application, you may also want a QA environment. This environment will consist of one or more servers that can simulate your production environment. The QA environment may or may not have production content, but it will certainly have all the "final" templates, user controls, or other components. Ideally, you will test all aspects of functionality and performance to determine if the application performs acceptably. If this environment is configured exactly the same as your production environment, you should be able to accurately predict the application's behavior once it's been moved to your production environment. CMS, in this environment, will likely be configured for Forms authentication to allow your QA staff to test the different user roles. A picture of a QA environment is provided in Figure 22-2. Keep in mind, when we cover the production environment, you should be able to see similarities in the logical configuration without some of the physical network security.
Figure 22-2. A CMS QA environment
Authoring in CMS does place a certain load on a CMS server and provides the ability to create content. As a result, Microsoft recommends that you have one or more CMS servers dedicated to content contribution. This environment not only reduces the load on the production environment, but also provides additional security by removing unnecessary entry points to CMS. This environment will consist of one or more authoring servers running a server edition of Windows in addition to one or more servers running SQL Server. CMS, in this environment, will likely be configured for Windows authentication without guest access enabled. Depending on the number of content contributors you have, the authoring environment may or may not be load balanced. In Figure 22-3 we've provided a picture of an authoring environment; we show a load balanced environment, even though it's not required.
Figure 22-3. An authoring environment for CMS
Some firms want to perform additional quality tests to ensure proper application function. Although the code should have already been tested in earlier QA phases, a staging environment allows content-specific testing. This environment will allow you to perform additional quality tests on the site as it might look in production. Unlike the earlier QA environment, which may not contain production content, this environment will have both production content and a copy of all of the production code. As long as you do not need to perform additional load or performance testing, it's unlikely that you'll need more than one server, running both SQL and CMS. There may be some confusion between this environment and the QA environment we discussed earlier, since they seemingly accomplish the same thing. However, unlike the QA environment, the staging environment is primarily for taking one last look at the content that's been contributed and pushing the content, templates, and code to production; think of the staging environment as the last stop before your application goes live. The staging environment, like the QA environment, will likely use Forms authentication to allow the content to be viewed by the various user roles that may be visiting your site.
NOTE: The staging environment is logically set up similarly to the QA environment we've discussed here, so we didn't provide a figure.
The last environment you need to create is the production environment. This environment will serve your site to all content consumers. You should have at least one database server and one CMS server. We would always recommend load balancing two CMS servers for any site, regardless of traffic; load balancing makes maintaining your Web servers easier by allowing you to take one down to install patches or software updates. In addition, load balancing provides application integrity by reducing downtime caused by hardware failure. You may also want to consider database server clustering.
Depending on the kind of production environment you need, you could have one of several different authentication methodologies, such as Passport, Windows, or Forms; in an intranet environment, it's likely you'll use either Forms or Windows. For an Internet deployment, you'll probably use Passport or Forms, and you'll also enable guest (anonymous) access, whereas in an intranet environment, guest access will probably not be enabled. In Figure 22-4 we've provided a logical diagram of a typical production environment.
Figure 22-4. A production CMS environment