Chapter 1: Deploying Phase

Following the Stabilizing Phase, the team shifts its focus to the deployment activities required to place the solution into a production environment. The Deploying Phase culminates in the Deployment Complete Milestone, where the team obtains final customer approval of the project. This chapter discusses the various key activities of the Deploying Phase along with the major tasks, deliverables, and tools.

On This Page

Goals for the Deploying Phase
Completing Deployment Preparations
Creating Operations Procedures
Deploying the Solution
Interim Milestone: Core Technology Deployed
Interim Milestone: Site Deployments Complete
Stabilizing the Deployment
Transferring Ownership to the Operations Team
Interim Milestone: Deployment Stabilized
Closing the Deploying Phase
Key Milestone: Deployment Complete

Goals for the Deploying Phase

The overarching goal of the Deploying Phase is to place the application into a production environment. Supporting goals include deploying the solution technology and components, stabilizing the deployment, and transferring the project to the operations and support teams. If the solution has been properly planned and developed before this phase begins, deployment is a routine activity. The groundwork for a smoothly functioning deployment was laid when the current application environment was assessed and documented during the Envisioning Phase and when the deployment plan was created during the Planning Phase. During the Deploying Phase, this deployment plan is further revised with the addition of more specific and up-to-date details about the deployment.

In some organizations, the project team is responsible for the entire deployment. In other organizations, there may be a group (such as a central engineering group or operations group) that is independent of the project team and who is responsible for deployment. For this reason, this chapter focuses on deployment tasks and issues instead of the persons responsible for these tasks. After deploying the application, the components are transferred from the test environment to the staging environment.

Major Tasks and Deliverables

Table 1.1 describes the major tasks that occur during the Deploying Phase and lists the owners responsible for achieving them.

Table 1.1. Deploying Phase Major Tasks and Owners

Completing Deployment Preparations

The project team can deploy the solution upon completion of the Stabilizing Phase. As the Stabilizing Phase nears completion, the Release Management lead assigns deployment tasks to the staff based on the deployment plan created during the Planning Phase.

The major activities involved with this task are:

• Creating the live environment.

• Deploying the migrated application.

You can typically deploy the Microsoft Windows environment using the Microsoft Windows Installer service. This method identifies a new deliverable in the form of an installer package (MSI) that can be applied by the Windows Installer service. Applications that target the Interix environment can rely on standard UNIX installation scripts. However, depending on the platform from which the application has been migrated, native binary programs for package management may be available.

The technologies for deploying Microsoft Interix, Microsoft Win32®, and Microsoft .NET applications are discussed in the build volumes (Volume 2, Volume 3, and Volume 4, respectively) of this guide. The following subsections only elaborate on the common activities shared by the three technologies: creating the live environment and deploying the migrated application.

Creating a Live Environment

This section focuses on the following topics related to implementing the migrated application:

• Interoperability

• Application deployment

• Network file systems and application servers

Interoperability

The team must address UNIX and Windows interoperability issues specific to the live environment. This is discussed in more detail in the “Operating a Mixed Environment” section in Chapter 2, “Operations” of this volume.

Application Deployment

For many organizations, deploying the new application is a major part of the migration project. Each of the build volumes (Volume 2, Volume 3, and Volume 4) of this guide provides a section, “Deployment Considerations,” in the “Deployment Considerations and Testing Activities” chapter, which discusses the tools and techniques that you can use to deploy the migrated application.

Networked File Systems and Application Servers

UNIX applications are often stored on an application server, and their executable files are accessed from the client using network file system (NFS) mounts. This greatly simplifies the deployment of applications because they need to be deployed to only one server (the application server).

If your migrated application continues to use application servers, there are issues that affect both Win32/Win64 and Interix implementations. The main issues arise because of differences in the ways that the UNIX and Windows networked file systems operate.

Migration to the Windows platform provides an opportunity to reevaluate whether to continue using application servers where applications are retrieved from local execution. Your evaluation must take into account the network bandwidth requirements and the proximity of network shares. You must deploy any Win32-based application using the Windows Installer service, regardless of whether it is located on an application server. This may entail as little effort as placing a shortcut on the desktop of the user, although most applications require at least some skeletal installation to accommodate Component Object Model (COM) or Distributed Component Object Model (DCOM) component registration, user preference settings, and building local configuration files. Creating .msi installation packages enables an enterprise to maintain a consistent technology, use Group Policy-based deployment, and enjoy wide support by other vendors of other tools. Consider that most applications will enjoy better performance and reliability when executed from local drives.

The specific details pertaining to each Windows technology have been covered as part of the “Development Considerations for Deployment” section in the “Closing the Developing Phase” chapter in each of the build volumes.

Deploying the Migrated Application

The deployed application consists of the following components that need individual configuration and verification:

• Physical environment. During the Planning Phase, the project team determined how the solution architecture will be configured, the specific types of hardware and software that will be required, how the software will be installed and configured on each computer, and what other components will be required to deploy and maintain the solution. In the Deploying Phase, the actual new physical and service hardware is built, and the software is installed and tested.

• System software. The project team updates the documentation of all system software, such as operating system, database platform, application server, Web server, and networking protocols used for the migrated application.

• Application software. The project team installs the software applications required to support the environment and the migration application.

• Custom application software. The project team installs the custom application software created by the development team on the servers in the environment.

Tools for Deployment

This section gives you an overview about the tools for deployment and the installation instructions.

You will need to perform the following tasks to deploy the application and tools:

• Distribute the application.

• Install the application.

Depending on the scenario, these tasks can be carried out together, or you can select and implement just one of them at a time. The build volumes of the guide discuss specific tools for deployment.

Distribution of the Application

Distribution is the process of getting the binary of the application to the system on which it will be run. Distribution can be conducted by various methods, such as:

• Copying all the files required for the deployment using a script on the local system. This could be performed with a simple Windows script.

• Copying the script and binary or the package to the local system with specialized tools.

The first method is not efficient because it chokes up the network and does not provide reliability and scalability. Moreover, it is difficult to get a report of the errors. One way to overcome this issue is to use the second method: Copying the script and binary or the package to the local system with specialized tools such as Microsoft Active Directory® directory service or using such tools as Systems Management Server (SMS) for distribution.

Active Directory

Active Directory is part of the Windows Server™ 2003 operating system and is a core feature that not only handles security and privileges of the domain, but also has the capability to distribute MSI files. Group Policy settings can be set in Active Directory to distribute the required MSI file at any given time to the necessary computers.

More information on step-by-step procedures for distributing an MSI file using Active Directory is available at

https://support.microsoft.com/?kbid=321713.

More information on Active Directory and its setup documentation is available at

https://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx

Systems Management Server

SMS is another tool from Microsoft that you can use to distribute the package. SMS has various features for packaging, distributing, and deploying applications in addition to monitoring them.

More information on step-by-step procedures for distributing a package using SMS is available at

https://support.microsoft.com/default.aspx?scid=kb;en-us;842844.

Installation of the Application

After packaging an application and distributing it to the local system, the next step is to install the application. You can deploy or install an application in the following ways:

• Using Windows Installer. Windows Installer is part of the Windows operating system and can understand and install MSI files.

• Using Wise or InstallShield. Wise and InstallShield provide their own proprietary scripts that can be understood by Windows as application-installable packages.

For more information on deploying an application, refer to the “Development Considerations for Deployment” section in the “Closing the Developing Phase” chapter of the build volumes (Volume 2, Volume 3, and Volume 4).

Creating Operations Procedures

The major role of the operations team is to maintain and monitor the application continuously after deploying the application. This section discusses the objectives, roles, and responsibilities of operations and how the operations team validates the project using various plans created during the Planning Phase.

Team Objectives, Roles, and Responsibilities

The operations team is represented on the project team throughout the project by the Release Management Role. As the Stabilizing Phase nears completion, the teams begin to transfer their activities and responsibilities to a deployment team. The operations team takes the responsibility, assisted by certain members of the development team, to help with deployment and stabilization.

Project Validation

The operations team validates the system’s environment, equipment, software, and configurations as well as the following plans:

• Disaster recovery plan. During the Planning Phase, the team creates a disaster recovery plan to maintain the migrated applications in case of crisis. During the Deploying Phase, the team reviews the document and validates and updates its contents. This plan should contain the potential risks and resolutions, the persons responsible for each component, and the methods for notifying management of any problems that occur.

• Business contingency plan. During the Planning Phase, the team creates a business contingency plan, establishing the course of action to take in case any business activity halts. During the Deploying Phase, the operations team reviews and validates the contents of the business contingency plan.

• Security plan. During the Planning Phase, the team creates a security plan. During the Deploying Phase, the operations team upgrades and confirms that all security procedures are in place. The team ensures that all permissible personnel are aware of the security standards and rules to which the project adheres.

Procedural Checklist

The operations team is responsible for maintaining and monitoring the migrated application on a daily basis. The team should create a checklist to avoid any potential issues with the migrated application. The team should consider the following factors when preparing the checklist:

• Dependency on the external tools or libraries

• Service packs, drivers, and new versions of hardware and software

• Data integrity and backups

• Capacity planning

Deploying the Solution

In deploying the solution to the production environment, you should consider the following factors:

• Transition to deployment

• Configuration management

• Readiness to deploy

• Deployment considerations

• Core solution

The following subsections describe the preceding factors in detail. The information provided here will assist you in deploying the migrated application to the production environment.

Transition to Deployment

The project team continuously updates and revises the deployment plan during the Developing and Stabilizing Phases. The Release Manager must review and revise the deployment plan and confirm that the development team has accomplished the following tasks:

• The deployment strategy is reviewed and approved.

• Setup, installation, configuration, test, operation, and support procedures are available, reviewed, and approved.

• Deployment procedures are documented, reviewed, and approved.

• Hardware and software components are available and tested.

• Ownership is transferred to the operations team.

It is vital that the project team continues to monitor the solution after deployment until the transfer of ownership is finalized. This allows the team to establish baseline performance records to track the performance of the application.

Configuration Management

Configuration management serves the same purpose for a deployed solution that revision control serves for source code under development. Operations personnel can use this configuration information to control the deployment environment. When deploying the migrated solution, it is vital for the Release Manager to provide all information required by the operations team for tracking configuration information.

Readiness to Deploy

The team should determine an application’s readiness for deployment after reviewing the test results and various checklists prepared during the testing activities in the Stabilizing Phase. The checklists are not intended to be decision-making devices. If the team finds any specific issue not on the checklist, it probably indicates that the application is not ready for deployment.

Deployment Considerations

A potential approach to take when going live is to review each layer of the architecture and run through the critical considerations. The considerations should be relevant to the database tier, the application and business layer, the presentation layer, and the general technical and business issues. The team should prepare a checklist with all the considerations for each of these layers.

Note   For more information on deploying an application, refer to the “Development Considerations for Deployment” section in the “Closing the Developing Phase” chapter of the build volumes (Volume 2, Volume 3, and Volume 4).

Core Solution

Most solutions include a number of code components as well as infrastructure components that provide the framework or backbone for the entire solution. These components do not represent the solution from the perspective of a specific set of users or site, but the deployment of the solution to sites or users generally depends on this core set of features or technology.

Interim Milestone: Core Technology Deployed

After the deployment of the core technology, all components that are part of the solution and its dependencies are in place, running properly, and sufficiently stable to move forward with site deployment components.

Interim Milestone: Site Deployments Complete

At the completion of this interim milestone, all targeted users have access to the solution. Each site owner has signed off that his or her site is operating, although there may be some issues. Some sites might have to be revisited based on customer feedback. To reach the Site Deployments Complete interim milestone, the team makes a concentrated effort to finish deployment activities and stabilize and close the project. This interim milestone is applicable only for projects that involve client-side deployments.

Stabilizing the Deployment

This section describes the activities that the project team needs to carry out for stabilizing the deployment before transferring ownership to the operations team. This section describes the steps to be considered for stabilizing the deployment, disengaging from deployment activities, and transferring the deployment to the operations team.

The Release Management lead assigns deployment tasks to the team. The team must review the project status and test results and update the deployment plan periodically. The team must also create task-based procedures that ensure successful deployment of the application.

The information gathered during the previous phases will help the team identify tasks that must be completed before transferring the application to the operations team.

Stabilizing the solution is a joint venture between the project and the operations teams. Stabilizing usually begins in the later part of the Stabilizing Phase and continues throughout the Deploying Phase as each solution component is put in place. It is important to include time in the master schedule for deployment stabilization because it gives both teams an opportunity to fine-tune the solution, resolve any issues that might arise, and monitor the solution to ensure that it continues to work properly after going live. It also allows the project team to assist the operations team after the transfer of ownership.

It is expected that some issues will arise with the various site deployments. These issues should be continuously tracked and resolved. At the Deployment Stabilized interim milestone, the customer and team agree that the entire solution is operating satisfactorily.

Disengagement Considerations

The team can find it difficult to close the project because of the ongoing issues that will surface after deployment. For this reason, the team needs to clearly define a completion milestone and criteria for the deployment instead of attempting to reach a point of absolute finality. Usually, one or two members will remain on the project for a short period of time to follow through on any problems or undocumented instructions. At this point, disengaging from the project includes transferring operations and support functions to permanent staff.

The Quiet Period

The period between the Deployment Stabilized interim milestone and Deployment Complete Milestone is referred to as a quiet period. The purpose of the quiet period is to measure how well the solution is working in typical operation and to establish a baseline for understanding how much maintenance will be required to run the solution. Organizations using Microsoft Operations Framework (MOF) will measure the number of incidents and downtime and collect performance metrics for the solution.

Transferring Ownership to the Operations Team

This section describes the steps for transferring the solution and the respective tasks and responsibilities of the project and operations teams. At this point, the project team must complete its final tasks, gather all produced collateral, and transfer the solution and the technology to the operations team. Relevant documents related to the migrated application must be updated to reflect changes in functionality and operation as a result of the migration. Some of these documents are:

• Deployment diagrams.

• Event-sequence charts from actual observations.

• Test plan including test reports.

• Reliability plan.

• Security plan.

• Backup plan to prevent loss of data.

• Plan for analyzing system performance and solution usage.

• Plan for log handling and other administrative tasks.

• Disaster recovery plan.

• Business contingency plan.

• Training information.

Transferring the Solution

Transferring the solution is the responsibility of both the project and operations teams. The project team will close any open issues and hand off maintenance activities to the operations team. The operations team will perform the specified activities and validate all collateral and equipment received from the project team. The following subsections describe the activities of both the project team and operations team when transferring the solution.

Project Team Tasks

The project team’s closing tasks include:

• Verifying that the operations team has the proper resources to maintain and manage the new solution.

• Confirming the final transfer of the knowledge base to the operations team.

• Reviewing operations logbooks and ensuring that the procedures are being properly performed.

• Reviewing configuration management data for the deployed solution to ensure that any changes in deployed components are accurately reflected.

• Reviewing Help documents for the migrated application.

• Reviewing training materials for the migrated application.

• Confirming that all project sign-offs are correct. After the signatures have been obtained, the transfer of ownership starts, and the operations team is solely responsible for the solution.

Operations Team Tasks

During the transition period, the operations team will work closely with the project team and complete the following activities:

• Activating all reporting systems.

• Validating and publishing all collateral.

• Validating and publishing the knowledge and databases.

• Reviewing training materials provided by the project team.

After these activities are complete, the project team transfers the solution and documentation ownership to the operations team.

Interim Milestone: Deployment Stabilized

At this milestone, the solution is deployed and has reached a quiet period where the operation of the solution is under control, users have started to receive business value from the solution, and the project is moving toward closure.

Closing the Deploying Phase

Closing the Deploying Phase requires completing a milestone approval process. The team needs to document the results of the different tasks it has performed to sign off on completion of the phase.

The deliverables checklist for this phase includes:

• Final versions of all solution documents, code, and test cases.

• Training documentation.

• Service level agreements (SLAs).

• Operations and support information.

• Customer and user satisfaction data.

• Project close-out report.

• Definition of next steps.

• Updated risk management.

• Milestone review report.

• Team member project progress report.

• Team lead project progress report.

Key Milestone: Deployment Complete

Download

Get the UNIX Custom Application Migration Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions