What Is Application Deployment?

Application deployment is the process of taking an application that has been developed and tested, and installing that application on target computers that require it. If you are going to be consistently successful in your application deployment, you need to ensure that you follow established best practices throughout the lifecycle of your applications.

Microsoft Solutions Framework (MSF)

MSF provides a series of best practices, principles and models that can be used to plan, build, and deploy solutions in an efficient manner.

The MSF process model is split into five integrated phases:

• Envisioning

• Planning

• Developing

• Stabilizing

• Deploying

Together, the phases form a spiral life cycle (see Figure 1.1 on the next page) that can apply to anything from a specific application to a complete environment.

Figure 1.1: The MSF process model v3.1

The process defined here shows the development of solutions from inception to complete deployment. The application development lifecycle includes many different processes, such as the actual coding of the application, the management of source control in a team development environment, the build process, the test process, the final packaging and staging, the deployment process, and often the upgrade of applications after they are installed in the production environment. All of these processes are to some extent interrelated, but in this guide we are concerned with the final part of that process, the deploying phase. As the diagram shows, this covers each of the processes from when the application is judged ready for release up until the deployment is judged complete.

Note

For more information on MSF, see http://www.microsoft.com/msf

The Deployment Process

Successful deployment relies on more than development of the application and the final packaging process. For example, applications need to be tested in a controlled way, and you should generally use staging servers between successful testing and final deployment.

The deployment process generally consists of managing your applications as they move through a series of different environments. These are:

• Development Environment

• Test Environment

• Staging Environment

• Production Environment

We will look at each of the environments in turn:

Development Environment

This environment is where most of the coding and developing takes place. Because your developers require sophisticated development tools, such as Visual Studio .NET 2003 development system and various software development kits (SDKs), this environment does not usually resemble the one where your applications will eventually be installed. However, the nature of your development environment does affect the deployment of your applications. Your applications are typically compiled and built in this environment, as well as packaged for distribution to the other environments. As such, you should be aware that applications which run without problems on development computers do not necessarily run as smoothly in other environments. The most common causes of this problem include:

• Dependencies required by your application (such as assemblies, Component Object Model (COM) objects, the .NET Framework classes, and the common language runtime) are present on the developer computers, but they may not be included or installed successfully in other environments. Some of these dependencies are present on your development computers simply because they are provided by the development tools and SDKs, so you need to be aware of exactly what needs to be deployed to ensure successful installation into other environments.

• Application resources (such as message queues, event logs, and performance counters) are created on developer workstations and servers, but they might not be successfully recreated or configured as part of the deployment to other environments. You need to thoroughly understand your application's architecture and any external resources that it uses if you are to deploy your application successfully.

• Applications are configured to use resources such as development database servers and Web services while they are being developed. When they are deployed to another environment, these configuration settings need to be updated so that they use the resources appropriate for that particular environment. Because many of these settings are stored in configuration files within the new .NET Framework, you need to manage the process of updating or replacing these configuration files as you deploy your application from one environment to another.

Test Environment

The test environment should be used to test the actual deployment process, such as running Windows Installer files, copying and configuring application files and resources, or other setup routines. You (or your test team) need to verify that application files and resources are installed to the correct locations, and that all configuration requirements are met, before testing the application's functionality.

After you are satisfied that the application installs correctly, you should then perform further tests that verify the application functions as expected. As well as simple functionality, the tests should include performance, stress and load testing. This will help to ensure that your application is deployed on the correct hardware, or over the appropriate number of computers.

To be certain that your tests have meaningful implications for how your application will install and function in the live production environment, you should ensure that test computers resemble your production computers as closely as possible. They should not have the development tools installed that you used to produce the application, because that could mask potential problems that will then only become apparent when you roll out your application to the end users.

Staging Environment

The staging environment is used to house your application after it has been fully tested in the test environment. It provides a convenient location from which to deploy to the final production environment. Because the staging environment is often used to perform final tests and checks on application functionality, it should resemble the production environment as closely as possible. For example, the staging environment should not only have the same operating systems and applications installed as the production computers, it should also have a similar network topology (which your testing environment might not have). Usually, the staging network mimics the production environment in all respects, except that it is a scaled-down version (for example, it may have fewer cluster members or fewer processors than your server computers).

Production Environment

The production environment is the "live" environment where your applications are put to work. This environment is undoubtedly the most complex, usually with many installed productivity, line-of-business and decision-support systems used by different users in the organization. Consequently, it is the most difficult to manage and control; therefore, administrators and information technology professionals are employed to ensure that users can take advantage of your applications along with applications from other vendors. The main goal of this guide is to provide guidance for allowing you to ensure that your solutions are installed successfully in this environment. It also describes various approaches for upgrading applications after they are installed in this live environment.