Deployment

Deployment requirements for an application can be stated simply as who are your users, where are they, and how do you deploy your applications to them? Getting the answers to these questions is not always an easy task. If you have a single-site environment, your deployment issues are fairly simple and straightforward. Having a multi-language, multi-national setup with many different categories of users on many different configurations or platforms can be a logistical nightmare, however.

Users can usually be separated into three categories:

• Standalone users Users who are not connected to a local area network (LAN).

• Remote access users Users who will gain access to the network through remote access modems.

• Local network users Typically corporate users who are connected directly to the network.

Understanding the deployment needs for each category is the key factor in having a successful deployment. Getting organizationwide input on deployment requirements for each category might seem an obvious plan, but too often groups of users, especially remote access users, are not considered when gathering deployment requirements. If possible, collect information from your project teams, staff, and user groups. You might want to conduct surveys or interviews to determine the full scope of your organization's deployment requirements.

Another factor in your deployment strategy is the operating system and configuration of users' computers. Some of the biggest problems during a distributed application's life cycle occur when your solution is rolled out to the production environment. An application that worked great in the development and test environment can behave completely different and fail miserably when brought up in the production environment. A major source of deployment headaches is machines with missing or outdated DLLs or other components that are supposed to be part of the standard installation configuration; your mission-critical application could then fail on a user's machine because he installed nonwork-related software that replaced a critical component with an older version than what you expected to be there. One deployment requirement that could evolve from this problem is expecting the machine to not have any critical components and adding them to the installation procedure. Unfortunately, this measure won't prevent corruption of the computer environment after some of the application's components have been replaced by the installation of another application. However, recovering these components would be possible by reinstalling your software after the corruption has occurred.

With a well-thought-out deployment plan and an understanding of the new application-deployment features available in the .NET Framework, deployment nightmares can be avoided. For example, one feature of the new architecture of the .NET Framework enables you to use simple copy operations for installing Windows Forms applications, instead of creating Windows Installer files. Modern .NET applications should rely less on Registry entries than traditional solutions do. That means assemblies do not require Registry entries, unlike COM components in the past. However, your solution might still rely on Registry settings in some cases.

The last major deployment requirement you need to determine is how the application will be distributed. The main force driving this requirement is the location and number of your users and what type of access (remote or network) they have. Many methods are available for deploying your application. These are the most common:

• Download FTP or Web sites on the Internet or intranet

• Network files

• CD-ROMs

• Multiple floppy disks

• A single floppy disk (Internet service providers only)

Based on the information you learn in the requirements-gathering phase, you can follow these types of deployment guidelines:

• For a large number of users or if the majority of users are at remote locations, you might want to produce and distribute the application on CD-ROM.

• For a smaller number of users, it might make more sense to distribute application packages over the intranet or the Internet.

• If your users are located worldwide, you might decide to distribute multiple-language versions of custom packages over the Internet.