Environments and Deployment

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.

Environment Guidelines

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.

• To begin, let's explore some of the questions you should ask as you plan your CMS deployment. Who is the primary audience of your application? Are the users of your application internal to your company (and your network), are they external, or are they a mix? Public facing applications have additional security requirements and should be more "locked down" than applications that are completely internal. An example would be a public Internet site verses an intranet application.

• How many content contributors will you have? How many content consumers will you have? These questions will help you determine the number of CMS servers you'll need for a given environment. For more information on capacity planning, refer to Chapter 35.

• Will you be hosting the CMS server internally or externally? If you're hosting CMS servers externally, you may want to limit the number of "moving" parts at the hosting provider. In other words, you probably only want to have one environment at the hosting provider and house all other environments internally. Also, most hosting services don't provide support for application servers like CMS, so it's a good idea to make sure that any environment that lives at a hosting provider be as clean as possible.

• Is the development of your CMS application done internally or externally? If it is primarily done externally, it may not be necessary to create a formal development environment; the group or firm performing the development will handle this environment. However, you may still want to have a quality assurance (QA) environment to allow your staff to properly test the application in your environment.

• Is there a need to "test" content? Some organizations need to provide an extra review of the site, even beyond the typical workflow that CMS provides. If you have this requirement, you may need a content QA environment (sometimes called a staging environment). This environment will allow various members of your organization to review the complete Web site before it's published to the production environment.

• How many developers are working on your site? The more developers you have, the more you need a technical QA environment where all the developers can contribute their code for testing. A technical QA environment will allow a group, other than the developers, to test all the components that have been written by the various developers. This environment could also be called "system test" since you're really doing a complete test of the application, as opposed to the component-level testing that a developer will typically perform. Another advantage of this environment is that it allows developers on the team to get the latest copies of code they're not writing.

• How often does your content change? If your content changes frequently, you may want to create a content authoring environment. This environment will contain one or more CMS servers that are set up primarily to accept content from contributors.

Creating Environments

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

Can You Combine the Authoring and Production Environments in One Physical Environment?

There are various opinions on whether the authoring environment and the production environment can be the same. Microsoft generally recommends that the authoring environment and the production environment be separate for performance and security reasons. It is technically possible to combine both logical environments into one physical environment, but we would not recommend this configuration in a public site, although it may be appropriate for an intranet application. The primary reason, beyond security, not to combine the environments is performance as you contribute content, you defeat your cache, thereby affecting performance (to what extent depends on your application). To determine the optimal configuration for your organization, you should consult network and software architects to review your specific requirements.