Product Deployment

A variety of deployment tools are available for presenting the application setup routine to the client workstation. Tools such as Microsoft Systems Management Server (SMS), logon scripts, e-mail distributions, and Web-based advertisements are available to aid in this process. The choice of the deployment tool depends on the application being deployed, the environment, the pace of deployment, and the expected skill level of the users. Each of these deployment methods will be discussed in detail later in this chapter.

Regardless of the deployment tools used to distribute the product, just as we discussed with developing the product, the deployment will fail unless it is planned properly. Creating a deployment plan and testing the plan before sending the product to the user community will help ensure a smooth transition for the product from the development process into the use and maintenance phases of the product's lifecycle.

Deploying the application by means of an e-mail distribution or Web-based advertisement requires somewhat more experienced users and a longer deployment timeline to allow each user to initialize the installation. Some methods allow for increasing user permissions on the local client more easily than others. If users have local administrative permissions or the computers are not tightly controlled, permissions are not an issue.

Using logon scripts to perform a deployment can be a very simple, effective, and quick method. This method does, however, require some interaction with users in that they need to log off and log on to initialize the script. This method also may not give users enough local permissions to perform the installation. If the local computer is not tightly controlled with permissions, logon scripts should work well.

Using SMS as the deployment method of choice eliminates some of the problems we've discussed. SMS does not require users to log off and log on to initialize the installation, as it takes care of the initialization itself. SMS can also modify users' local permissions to get around local client systems that may be locked. The need for users to understand the deployment process is minimized because the system administrator determines and controls the deployment process. SMS makes managing the distribution easier by automating issues such as the targeting and scheduling of the distribution and the notification of clients about the details of an upcoming release.

Planning the Product Deployment

In the deployment of any software application, there is some risk of incompatibility between the new application and a user's existing software, operating system configurations, or hardware drivers. Planning and testing of the application deployment are essential steps in the overall development process, forming the yardstick by which the success of the project can be measured.

Planning takes into consideration the human and technical resources needed to deploy the application, from staff who will support the users throughout the deployment period to the network circuits that will deliver the application source code to the client's workstation. The planning goal is to define the resources needed for all aspects of deployment, and to estimate as accurately as possible the usage and schedules of those resources.

Testing measures this usage in a controlled environment, such as a computer lab or a pilot group on the production network. The metrics collected from the testing may indicate a need to make adjustments to the resources for the actual deployment. Success in one or two areas of the deployment does not necessarily indicate overall success. For instance, an application setup routine may install flawlessly, but lack of experience on the part of users could create problems, such as an unacceptable load on the Help Desk support staff.

Planning and testing are invaluable processes that should not be skipped, because they always provide some insight into the deployment process.

Dealing with multifaceted and dispersed locations adds complexity to an application deployment. A deployment plan must be created that takes into account locations, organization, connection speeds, server load, and deployment timelines. For deployment, organizations and users should be categorized based on different structures such as physical location, departmental organization, and network topologies.

Location

Organizations and users are often categorized by physical location, but they can also be subdivided according to which server is used as their primary logon validation server.

The easiest system to plan for is a deployment that is based on physical location, whereby each location has its own logon validation and file server. This server can be used as the distribution point for the application to that location. When each physical location does not have its own file server, connection speeds must be evaluated to determine which server should be used for the application's distribution point.

The team must take great care to consolidate clients into distribution groups according to their location breakdown, and it needs to be aware of several issues when deploying an application to multiple physical locations. In the initial phase of deploying the application source code, the deployment can be limited to a small number of distribution points. In large-scale deployment, it's critical that the source code be sent to the application distribution points a minimum of one week before the deployment to clients. This lead time provides enough leeway to confirm that the source code arrived successfully at the distribution points and allows time for resending if necessary. Once the real deployment process begins, the team must take care to ensure that the application is deployed only to clients where the source code is available.

Organization

Organizing a deployment by department can create some additional complications during application deployment. A company may want to deploy an application to everyone in a department even if that department spans several physical locations and possibly several security domains. Careful deployment decisions must be made when dealing with such a situation. The department's clients should be grouped into multiple deployment groups based on their physical location and their application distribution server. It may even be necessary to break the target group into different client groups or different network connectivity groups. When the application is actually deployed, it's important that all the clients in all the department's groups receive the application within the same time frame. Before sending the application, the team should verify that each of the distribution sources is in place and that the connectivity to the various clients exists.

Connection Speeds

Connection speeds are probably the easiest item to overlook when deploying an application, but one of the most important items for ensuring a successful and timely application deployment. Two types of connections can significantly affect deployment:

• The connection speed between the original application source server and the remote application distribution points used by the actual deployment process.
• The connection speed between the distribution point and the client computers.

When planning the distribution of the source code from the original source location to the application distribution point, it's important to identify the slowest connection link. With proper planning, this distribution can take place at low network volume operating times and should have minimal effect on overall network operations. If network connection speeds are very slow, the source distribution should be planned for a weekend or an extended low-network-utilization period. If the application is large and the connections are extremely slow, we suggest that the code be distributed by an alternative method, such as a portable hard drive, CD-ROM image, or other large portable media.

Server Load

In conjunction with the connection speed, the team must consider the load that the deployment will create on distribution points. This load should be monitored to ensure that the normal daily tasks of the server can be carried out without degradation. Other items that might need to be compensated for are databases, domain controllers, e-mail servers, file servers, and Web servers.

As the number of connections to the application distribution point increases, the installation speed typically decreases. Having adequate processor speed, sufficient RAM, and adequate connection speed on the distribution servers can minimize this effect. To alleviate some load on the server, the number of deployments by the server can be reduced in specific time periods.

Deployment Timeline

When deploying a large application, the deployment timeline must be planned in detail and then modified based on testing. Gathering deployment and installation statistics during the initial stages of deployment testing is crucial in determining a realistic deployment timeline. These statistics should include:

• Connection speeds to the distribution points and from the distribution points to the clients.
• The distribution server load.
• The quantity of distributions during each phase of the deployment.

One source of information that is often overlooked is the volume of Help Desk calls generated by an application deployment. Some calls are simply for information about the deployment schedule and others are for instructional help. These calls need to be closely monitored to determine whether the deployment timeline is too aggressive or whether unforeseen issues are arising in the deployment process. A manageable volume of Help Desk calls is a positive sign that the deployment process can move forward and that the number of installations per time period can be increased.

Software, Data Setup, and Conversion

After the installation of the application has been verified, the users will need a way to migrate or convert existing data from earlier versions or from other data sources. This process will vary depending on the application, but many tools exist to facilitate migration and data conversion.

It is important to make the process as automated and painless as possible. Three methods to consider are:

• Upward compatibility The easiest migration is when the new application handles old data directly without any intervention. In this case, users simply open their old documents in the new application.
• Common format This method requires that the old data be saved in a format that both the old and new applications can handle. This process is usually straightforward once the common format is identified. Users can convert their files to this common format if their knowledge level and time allows, but it is sometimes more effective to create an automated process to convert all the files to the common format. (Automatic conversion may present a challenge if the files to be converted are dispersed among multiple servers and be even more of a challenge if they are dispersed among multiple workstations.)
• Specialized application An application can be created to convert old data to a format that the new application can handle. (The conversion application could perform double-duty by removing extraneous information from the old data files.) If the new application accesses databases or data warehouses, it may be useful to convert data from flat files, relational databases, and other formats using the Microsoft Data Transformation Services. This utility is provided with Microsoft SQL Server 7.0 and provides an easy way to convert, manipulate, and validate data being transferred from one data store to another. The data conversion destination is not limited to SQL Server databases, but can also handle third-party platform destinations.

During a managed deployment process, documents already opened in the new application may need to be used on a computer to which the new application has not yet been deployed. The best way to avoid this problem is to deploy the application on a department-by-department basis.

Whichever migration method is selected, its process must be clearly communicated to the users, especially if they are expected to complete the process on an as-needed basis.

Interim Product Release Deployment

In deploying the interim product releases, it should be assumed that the instal-lation process itself has progressed to the point of zero defects. To have zero defects, the installation process must correctly identify and handle multiple versions of the operating systems that are used throughout the organization. The process must install the correct .dll files, .ini files, or other files required by each version of the application and the target user's desktop operating system. Care must be taken to deliver all of the correct files with each product release, as users testing the product must be able to receive subsequent releases to the same desktop computer.

In deploying the interim releases, the team must also test the interactions of the application with the applications already installed on the client's system. Troubleshooting in this area of deployment can be difficult because of the wide variety of applications being used, and separate testing is often required. Full testing of all the applications would take considerable time, and the team may find it necessary to prioritize, testing only the most widely used applications.

Previous product installations, along with the interim product release deployments, allow the team to forecast the load on the organization's support staff and Help Desk. This part of the deployment process directly affects how quickly and when deployment takes place. The team should allocate time for educating the support staff and Help Desk staff about how to assist in the deployment process and resolve simple issues. This education may be in the form of an instructional paper distributed to staff, or in a meeting to allow a two-way discussion about what to expect. Whichever means is used, it's critical to the success of the deployment that the Help Desk load be forecasted in advance, and that a team approach to the deployment be adopted.

By providing some training, a team can drastically reduce the number of support calls they receive and enhance users' acceptance of the deployment. Training users on the application helps separate the deployment installation questions from the application usage questions. It may even be possible to route support calls related to application-training issues separately from general support problems.

Deployment Methods

There are numerous way to deploy a product. We'll discuss several effective methods for product deployment such as Microsoft's Systems Management Server (SMS), logon script distribution, e-mail distribution, and Web-based distribution.

Systems Management Server

The most effective deployment system is SMS, which enables system administrators to handle the distribution and organization of the deployment in a controlled and preplanned manner. SMS also frees users of the responsibility of deployment, which can even be performed without the users' knowledge or intervention.

When building an SMS deployment system to handle a specific application, several factors must be considered. The extent of the deployment and the size of the application being deployed greatly affects the system and how it handles the distribution. A properly developed SMS system disperses distribution servers according to the location of the clients and the speed of the network. The process of building the deployment mechanism within an SMS system requires organization of the client systems into specific groups, based on features such as physical locality, department, or client operating systems. Figure 13.2 shows the flow of an application package and advertisement instructions from the master source at the SMS site server to a local distribution point source and the client access point. The targeted clients poll the client access point periodically and connect to install the package at the specified time.

Figure 13.2 SMS software distribution process

During the testing phase of the SMS deployment system, a note should be made of the time required to distribute the application code from the source to the distribution points. It's highly recommended that a variety of speed connections be tested, from the fastest to the slowest. Collecting data during this test distribution helps to calculate the time that will be required to fully distribute the application source code. Testing multiple installations from the same distribution point is necessary in order to obtain the server load information. This data can be used to determine the total number of installations a distribution point can handle.

Another item worth evaluating during the testing process is how the test users react to the installation. This information can be helpful in estimating how many Help Desk calls to expect.

Logon Scripts for Deployment

Another method of distributing applications is via logon scripts. Logon scripts are effective in distributing applications to the general public, but some safeguards must be in place. Some factors to take into consideration when using logon scripts include:

• The possibility of repetitive installations.
• Whether the application installation requires only a single installation per computer or an installation for each user of the computer.
• How deployment to specific groups, other than those in Windows NT groups, should be controlled.
• Whether shortcuts need to be created at the user level for a machine-level installation.

The logon-script deployment of applications is primarily controlled by system administrators, but users must still log off and log on to receive the distribution. When creating the logon-script system, proper groupings and scripting conditions should be implemented. The installation script should be able to recognize the various client operating systems. Groupings should be created to control the deployment of the application. The application portion of the logon script should have the built-in intelligence to recognize whether the machine has previously been updated. The script should also handle the creation of user-level shortcuts, and recognize how to avoid multiple installations.

Testing of a logon-script deployment system is fairly straightforward in that users need to be added only to the testing group. After the group membership has been updated, the test users can log off and then log on to have the implementation take place. The script installation process should be logged to allow for intelligent modifications to the deployment script. Information should also be gathered to help determine whether additional load is created in the morning hours by the logon process and the typical high volume of system usage during this period.

E-Mail Distribution for Deployment

Another way to deploy applications that may be appropriate for some organizations is via e-mail. The following considerations are specific, though not necessarily unique, to deployment by e-mail:

• Using this form of deployment requires additional intelligence that must be built into the application installation package.
• The installation package must be able to determine the client operating system.
• The installation process must be able to accommodate multiple source servers.
• The e-mail system must be able to handle clients who are performing the task over a remote access server (RAS) or slow wide area network (WAN) connection.
• This form of deployment must also establish policies for installing applications across a dial-up networking connection that might be performed on personal home equipment.
• The application could also be created so that it is small enough to be contained within an e-mail message.

The one large flaw with using e-mail as a deployment method is that it relies on the user to initiate installation by opening the message. To circumvent this, the e-mail deployment system can be designed to automatically launch the installation, which would prevent cancellations caused by the user deleting the message.

During the testing phase of an e-mail deployment system, statistics should be gathered on the success of the installation, the likelihood or number of cancellations, and the time required to install. As with the logon-script system, an increased load will be experienced during the early morning hours because of new incoming e-mail.

Web-Based Deployment

Web-based deployment is another viable means of distributing applications. Like the other methods, this one needs to handle multiple distribution servers. This method also relies on users to check the Web location on a regular basis and then initialize the installation. If the application is needed and the knowledge level of users is adequate, a Web-based application may be the best option for an organization. The Web application page must be accessible to all employees who will need the application; creating a simple yet effective page that all users can understand is a key factor in the success of this method.

We suggest that the team work with users of varying skill levels to test a Web-based installation. Input from them on page layout and ease of use during the testing phase reduces the number of Help Desk calls. A logging system should be put in place to determine on which computers the application has been installed.

Production Support

Creating a load-balanced fault-tolerance system can increase the application's uptime.

Windows NT Load Balancing Service (WLBS) can be implemented to create redundancy and fault-tolerance in a Web-based database application system. WLBS allows front-end Web access to have redundancy and can load-balance up to 32 servers, meaning that if a server goes offline, the load is automatically redistributed to the remaining servers. When the offline server recovers and rejoins the WLBS system, the load of the system is then redistributed.

Clustering on the database servers can also be used to allow fault-tolerance on the database engines. Clustering of the database engine servers makes it possible to reduce the load on each server. If a failure occurs on one server, its load is redirected to another clustered server. Under normal working conditions, the cluster separates the database processes and allows for faster access to the shared data drives.

Testing of the fault tolerance system should be done during the deployment testing or the pilot testing periods to ensure good performance.

Data Migration and Coexistence Issues

Some application deployment issues are generated when a system is converted from one server operating system to another. For example, organizations converting from Novell NetWare file servers to Microsoft Windows NT servers find that the application deployment process must handle a transition period until all client applications are converted to the new system. This often means maintaining data access for both platforms. If a limited number of people maintain and update the data, the application should be deployed to their computers either first or last. Then the data should be duplicated between the new system and the old system in a timely manner, until the total deployment is complete. If a large number of people can change the data, a gateway system should be implemented from the new system to the old system to help maintain accurate data access. After the completion of the deployment, the gateway system or data duplication can cease, and the application can be fully switched to its permanent configuration and file server operating system.