Certification Objective 8.02: Developing an Appropriate Deployment Model

Deployment is the process of moving an application from the development environment into the production environment. Depending on the application, the process of deployment can take anywhere from a few minutes to several months. A deployment model is a strategy that ensures a successful deployment.

When designing a model that ensures a successful deployment, the following issues should be taken into consideration:

• Deployment specifications

• Licensing specifications

• Data migration specifications

• Upgrade path

In this section, you will learn how these issues affect deployment.

Author's Note

Microsoft TechNet contains an excellent deployment guide to help you design a deployment model at http://www.microsoft.com/technet/itsolutions/net/deploy/netdgv2.asp.

Creating Deployment Specifications

There are five main methods for deploying Microsoft .NET applications:

• XCOPY

• Windows Installer

• MSI database utilities

• Microsoft Application Center 2000

• Microsoft Systems Management Server (SMS)

XCOPY is a command-line utility that can be used to copy files and directories en masse. .NET assemblies can, in most cases, simply be copied to the desired location on the target computer. The need for registering components or placing them in a specific directory such as C:\WINDOWS\SYSTEM has also been eliminated, making this type of deployment easier. The drawback to using XCOPY deployment is that the application will not get added to the Windows Start menu, will not be listed in Add/Remove Programs in the Control Panel, and a desktop shortcut icon will not be created.

Windows Installer replaces the Windows Cabinet (.CAB) deployment model in older versions of Windows. Windows Installer files end in the extension .MSI, and provide a flexible method of installation.

The MSI database utilities, contained in the msidb.exe tool, can be used to export and import Windows Installer databases, merge .MSI files, and apply certain transformations to these databases.

Microsoft Application Center 2000 provides tools for deploying .NET applications in a web server farm or load balanced environment. The servers in a multi-server environment can be treated as a single server, making things much easier to administer. Application Center can also be scripted using an API it exposes.

Microsoft Systems Management Server (SMS) is a software management tool that allows system administrators to manage hundreds or thousands of Windows computers remotely. It allows administrators to install new software to some or all of the desktops in an environment, monitor everything that is installed on each machine, and track the hardware/software configurations from one central location. SMS has been around for many years and is an established method of software deployment in many organizations.

Creating Licensing Specifications

It’s important to understand what the licensing issues surrounding deployment are before development begins on an application. If you decide to use a third-party component in your application, you need to understand how much it will cost you to license use of that component and how to go about obtaining that license in case you discover too late that a component cannot be licensed due to cost or other factors.

There are usually two main issues surrounding licensing in a commercial application environment:

• Cost

• Usage restrictions

The issue with cost is fairly easy to understand: if you want to include software that is copyrighted or patented by someone else, you generally have to purchase or acquire a license for it. For instance, if you decided to develop a video player that includes support for the MPEG-4 video compression format, you will probably have to pay royalties to the Moving Picture Experts Group Licensing Administrator (MPEG LA) to gain the right to do so.

Other licensing costs relating to application development are for third-party applications that your application relies on. For instance, if your application creates Excel spreadsheet files, you will have to consider what the cost of providing everyone with a copy of Microsoft Office would be.

The second issue related to licensing is usage restrictions. Some software is licensed to all at no charge. The open-source and free software covered by the GNU Public License (GPL) comes to mind. But that license includes terms that restrict how the software can be used within other applications, sometimes including the requirement that any developers using the software must also release their source code under the GPL.

Creating Data Migration Specifications

As we stated in Chapter 5, a well thought-out database design will influence application design in a positive way, while a poorly thought-out database will have the opposite effect. One consideration that generally does not impact the database design process until this point is the nature and format of the existing data. Data migration is the process of transforming data from one format into another.

Author's Note

Data migration can sometimes be an irreversible process, such as when data is being modified “in place.” That is, the data inside existing tables is simply being updated, not copied. It is a good idea to perform a database backup before performing the migration in case something goes wrong.

If your data currently exists as a stack of file folders sitting in large metal filing cabinets, you need to give some serious thought as to how you’re going to get all that data into your application. Even if your data already exists in some electronic format, it is a wise idea to think about the logistics of transforming that data into the new format required by your application.

Some of the considerations that a data migration specification will have to take into consideration are

• What format is the data currently in?

• Will this be a one-time migration, or will you have to perform this task again several times in the future?

• Are there any other applications that rely on the data in the old format or location? Will data have to be maintained in two places?

• What tools can be developed or are already available to make this task easier?

The purpose of data migration specification is twofold. First, this specification needs to define the column mappings from the old data format to the new. For columns that did not exist in the old format, what defaults will they acquire?

The second purpose is to identify the logistical challenges (such as timing) with the data migration, and define how they will be overcome. For instance, if the database is extremely large, data migration could take hours. It is best to identify these potential issues early, before encountering them during the deployment process. If you schedule a deployment to take 2 hours, and then realize database conversion alone will take 18 hours, it will be too late to do anything to mitigate that.

One important point to remember when designing a data migration plan is that it is a good idea to include the use of a log file in your data migration script. After the data migration is complete, you should examine the log to determine what error messages were encountered along the way. This will allow you to fix the cause of the errors before running the script again.

On The Job

In my experience, data migration is not usually a one-time event. You will likely want to test your data migration scripts out several times before running them in the production environment. You will also want to pre-populate the development and quality assurance (QA) databases for testing purposes. There will be times when the database gets into a state where it needs to be refreshed. Be prepared to run the data migration scripts several times, which is a good thing since it will help you find bugs in the scripts.

Designing the Upgrade Path

Deploying the first version of an application is usually quite straightforward—you just install the application. Not that the process of deployment is always easy, we just mean that you do not have to deal with the complexities of existing files, folders, applications, and settings.

When dealing with subsequent releases of your application, you always have to give some thought to the upgrade path. The upgrade path is the process of moving your users from the older version of the application to the new one, with as little hassle as possible. Some of the issues you may encounter when deploying an upgrade are

• Stopping the existing application if it is running

• Overwriting existing files and folders with newer versions

• Deleting application files that are no longer needed

• Retaining user settings and preferences

Alternatively, some applications choose to ignore the fact that a previous version existed and simply overwrite the older version as if it were a new installation. Other applications even require users to manually uninstall older versions of an application before the installation of the newer version can proceed. Neither of these alternate approaches is user friendly or necessary. A properly designed application will make it the upgrade path easier for users. Steps will usually be taken during the design stage to separate user settings into a separate file, and to standardize on file names and locations, to make it easier to upgrade the application in the future. The .NET Framework even allows applications to be upgraded while they are running.