Chapter 19 - Deploying Phase

  • Article
On This Page

Introduction and Goals Introduction and Goals
Deploying the Solution Deploying the Solution
Stabilizing the Deployment Stabilizing the Deployment
Transferring Ownership to Operations Transferring Ownership to Operations
Conducting Project Review and Closure Conducting Project Review and Closure

Introduction and Goals

After envisioning, planning, developing, and stabilizing, the solution is ready to be deployed. The Deploying Phase implements the tested solution in the production environment. The migration project Release Management team deploying the solution works with the operations team to successfully deploy and stabilize the solution. At the close of the Deploying Phase, customer approval for the migration is obtained, and the solution is transferred to the operations team. It is also possible that the operations team handles the deployment with the aid of the project team. Irrespective of which team does the deployment, the key goal of the Deploying Phase is to successfully migrate the new solution into the production environment as smoothly as possible, and with the least amount of disruption to the business environment or the end users.

The deployment rollout should be conducted as a series of activities. Though you can abbreviate or combine some of these activities, you cannot skip any of them completely without increasing risk to the project's success.

Nearly all of these activities are performed in conjunction between the project team and the operations team. Coordination between the two teams is now a critical success factor. All decisions should be agreed upon by both of the teams to minimize risk. Both teams are involved with completing the tasks and producing the deliverables shown in Table 19.1.

Table 19.1: Major Tasks and Deliverables for the Deploying Phase

Tasks

Deliverables

Responsible Roles

Deploy the solution

Deployment Checklist

Release Management

Stabilize the deployment

Deployment Checklist

Release Management

Obtain the solution signoff

Customer Sign Off

Product Management

Transfer ownership

Project Documents

Program Management

Deploying the Solution

At the close of the Stabilizing Phase, the database and applications (server side and client side) are fully tested and are ready for deployment. The release versions of the source code, executables, scripts, and other installation information are complete and delivered to the deployment team.

While deployment is often discussed and planned singularly, there are actually three separate components and technologies that must be deployed into the production environment. These solution components are:

  • Database server

  • Server side application(s)

  • Client side application(s)

Each of these components is discussed in this section. Each of these topics is divided into two subtopics: process and technology. The process subtopics provide an overview of the intricacies involved with the deployment of each of the solution components. The technology subtopics include information on software tools that can assist with the deployments of the solution components.

Deploying the Database Server

The database should be deployed first because the server side and client side applications are dependent on it. The process and technology required for setting up a database server and implementing databases are discussed under the following headings.

Process

During the Planning Phase of the migration, all hardware needs are evaluated and any required new equipment is acquired. During the Deploying Phase, the server must be set up and configured for the Windows Server™ 2003 environment. The following procedure describes the steps for deploying the database and its server:

  1. The server should be built and delivered by your hardware vendor based on specifications defined during the Planning Phase. If the server will be built from existing equipment, ensure that the server is available and has the required capacity to host the solution.

  2. Install any necessary hardware. Commonly, items such as additional memory, interface cards, additional storage, tape drives, or FDDA gigabit switches will need to be installed to meet operational specifications.

  3. Install the operating system, including any necessary service packs and patches. This step can be performed manually or by using imaging software. This topic is discussed in greater detail in the technology portion of this section.

  4. Configure any additional hardware that was installed. For instance, if NIC cards are installed, they must be configured to match the settings of the network switch they will connect to.

  5. Install any additional applications needed for the server, such as monitoring applications, backup software, asset management software, and software delivery applications.

  6. Select the deployment mechanism for the database. Some possible options include:

    • Use automated processes, such as installation and configuration scripts, where possible.

    • Use manual processes for some installation and configuration. These must have detailed, step-by-step instructions.

  7. Create the database deployment package by putting together the following:

    • Microsoft® SQL Server™ installation and configuration scripts.

    • Database administration tools and utilities.

    • Database administration scripts and a scripting language such as Perl.

    • User database migration scripts.

    • Database administration tasks and packages, such as a maintenance plan, jobs, and backup and restore procedures.

    • Windows® domain user accounts configuration scripts.

    • Scripts for configuring ODBC data sources, ADO, and OLE DB connection strings.

    • Scripts for configuring COM+ components for database connection.

  8. Create rollback scripts to undo or remove changes introduced by the deployment. If a parallel cutover strategy is being employed, the scripts should disable the replication. Not every aspect of the fallback can be scripted. A checklist of tasks with detailed instructions should be prepared.

  9. Add the deployment package to the configuration management database (CMDB). Maintain change control of the release. Where a CMDB does not exist, a simplified one should be created for release-tracking. The purpose of updating the CMDB is to ensure that accurate knowledge is stored regarding all of the components or configuration items that make up the releases.

  10. Execute deployment package for the databases being migrated as per the phase-out strategy.

  11. Execute the scripts to create the database and its objects. The serial cutover strategy will dictate the order in which the databases are migrated.

  12. If a straight cutover strategy is used, shut down the Oracle databases. If a parallel cutover is used, the databases may not be shut down. However, a quiet period is required to enable the replication and ensure that the replication mechanism is working properly. Start migrating the data.

  13. Monitor the data migration for errors. If the migration has to be aborted, the rollback scripts and other fallback steps should be performed for each of the databases affected by the failure (if the databases are related and have to be migrated together).

    Note If you must deviate from these scripts in the production environment, make sure to alter the scripts to reflect the change and enter a note in the script or documentation regarding what was altered, why, and whether you noticed any issues afterward.

Technology

Setting up and configuring servers can be time-consuming, especially if additional applications are needed for operations, monitoring, reporting, or other purposes. Based on the needs of the deployment, there are two ways to deploy the server: manual deployment and automated deployment using imaging tools. Imaging tools allow for applications, operating systems, configurations, or drivers to be installed in one package, instead of as individual installations. However, imaging can only be useful when setting up identical servers using identical hardware, as in a clustered set.

Manual Deployment

If a manual deployment is a consideration, a few guidelines should be noted. Often, hardware vendors will provide customized installation CDs that contain specific drivers and software needed for the configuration. Using these installation discs can reduce the time needed for installation.

For the detailed manual installation procedure and configuration of Windows® 2000 Professional, Windows® XP, Windows Server™ 2000 Advanced Server, and Windows 2003 Server Enterprise Edition, refer to the help documentation provided with the Windows operating system CD.

Note Manual installations of the operating system can be partially automated using an answer file. This file provides the input that the setup needs to perform the installation and reduces the amount of user interaction needed during the installation process. For details about creating an answer file and the options available in an answer file, refer to https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dghn_ans_wten.asp.

Another tool that can be utilized to assist in manual deployments is Microsoft Remote Installation Services (RIS). RIS enables you to perform system installations across a network using an Active Directory service. For more information on RIS, refer to https://www.microsoft.com/windows2000/techinfo/planning/management/remotesteps.asp.

The RDBMS should be installed manually using the Microsoft SQL Server Software Distribution CD or a network installation tool such as RIS. For more information on the installation process for SQL Server 2000, refer to https://msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_overview_0v3l.asp.

Creation of the databases and database objects can be performed using Data Definition Language (DDL) scripts that have been generated from the test environment. This information can also be recreated manually using the Enterprise Manager GUI, but in most instances the large number of objects that need to be created would make this effort too time-consuming.

To create a database using the CREATE DATABASE command, refer to https://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_create_1up1.asp.

To create a database using the Create Database Wizard in Enterprise Manager, refer to https://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht_7_design_4g8p.asp.

DDL scripts can be run using Query Analyzer, a utility installed as part of SQL Server. Third-party SQL Server tools can also be used. For more information on Query Analyzer, refer to Appendix B.

Automated Deployment

Imaging is an alternate method of deploying the operating system and all applications and configurations simultaneously. Imaging captures a snapshot of the entire system, including the operating system, applications, desktop settings, and user preferences.

Imaging tools should be a serious consideration for deployments that consist of multiple servers that require the same configuration. Creating images can greatly reduce the time needed to prepare servers for deployment and also ensure consistent configuration.

To create an image, a master system must be manually configured with all necessary software. After the server has been properly configured, the image is created using imaging software. Finally, the image can be deployed to as many servers as required. Each will be a clone of the master system.

The major benefits of using the imaging tools include:

  • Deployments can be performed simultaneously. All systems can be running in a short time.

  • All applications are bundled into the image.

The major drawback of imaging is that each type of hardware configuration requires a separate image. You can only install images on target computers that have a compatible hardware abstraction layer (HAL) to the reference computer. For instance, if a server contains a different graphics card, it would require a separate image.

There are many different tools and utilities available that provide the capability to record and deploy images. Here is a listing of some of these tools:

Deploying the Server Side Applications

The steps for building the servers described in the previous section can also be used to prepare the servers for the server-side applications. Detailed guidance for setting up the server-side applications is discussed under the following headings.

Process

Though the server will be set up to meet the needs of your specific applications, additional steps may be needed to prepare the hardware for deployment.

To deploy server-side applications, follow these steps:

  1. Install the operating system and third-party components on the server as required by the application.

  2. Configure the server-side application components.

  3. Install the server-side components on the server.

  4. Add all configuration information into the configuration management database (CMDB) and maintain change control of the release. If a CMDB does not exist, a simplified one should be created for release-tracking. Updating the CMDB ensures that accurate knowledge is stored regarding all of the components or configuration items that make up the releases.

  5. Deploy the applications in conjunction with the deployment strategy being employed for the databases.

  6. After the database migration has been confirmed, perform configuration changes to the environment to activate the application.

  7. If a fallback is required, then the application should be shut down and the original configuration that points all users back to the original application should be restored.

Technology

The server side application components can be either deployed manually or by using imaging as discussed in the "Automated Deployment" section.

Manual Deployment

If manual deployment is chosen, each of the components of the server-side application should be individually installed. First, install the language environments (such as Perl and PHP) and any third-party utilities using the vendor's software distribution. Then install the server-side application using the golden version of the source code from the project team.

Automated Deployment

The deployment of the server-side applications can be automated by bundling it into the image. The technology is the same as discussed for deploying the database.

Deploying the Client Application

After the server-side applications and databases have been deployed to production and tested, the client application should be released. Often, this stage of the deployment can be complex because of the number of users and components involved.

This is usually the point in the deployment process where the end users are affected. In many cases, this is the first time that they are involved in the migration process. While this guidance focuses on the application and database aspects of the migration, keep in mind that there are many other items to consider. For instance, documentation, training, and help desk support also need to be in place at the time of this deployment.

It is quite likely that the client computers are already in use. If not, build the hardware for the client computers and deploy the required software.

Process

As with the other stages of deployment, the client application can be deployed manually or through the use of automated tools. Consider the following steps when deploying the client application.

  1. Create the deployment package, which can include the following:

    • The complete application, including the binary installation files and any automation files.

    • Client configuration and support files.

    • Windows domain user accounts configuration scripts.

    • Scripts for configuring ODBC data sources, ADO, or OLE DB connection strings.

    • Scripts for configuring COM+ components for database connection.

    • Acceptance test scripts and packages.

  2. Create rollback scripts to remove changes introduced by the deployment. Rollback scripts provide an alternate option if an uncorrectable issue arises during the server, database, or application deployments.

  3. Add the deployment package to the configuration management database (CMDB). Maintain change control of the release. Where a CMDB does not exist, a simplified one should be created for release-tracking.

  4. When the database and application migration are completed successfully, deploy the client application. In addition to the database and application deployment strategy, a horizontal phase-out strategy may be employed for client applications.

  5. If a fallback is required, then the application should be rolled back to the previous one and the original configuration that points all clients back to the original application should be restored. If the fallback is due to an application issue, then a horizontal phase-out strategy reduces the rollback effort.

Technology

When deploying the client application, additional tools may be required to efficiently manage the deployment. Some common tools used for packaging applications and utilizing distribution channels include:

Change Management

Change management is the process for controlling changes to a protected environment. In the Stabilizing Phase, changes are made to the test environment related to bug fixes and promoting the builds. Changes made to the solution in the production environment are handled more strictly because they can affect the end users of the application as well as other users of the production environment. Any proposed changes must go through the change approval process to ensure that the changes will not adversely affect the production environment.

For detailed information on Change Management, refer to https://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx.

Stabilizing the Deployment

After the server-side application components, database, and client-side application components are deployed, every aspect of the deployment must be validated to ensure that the migration has been performed successfully. Common items to check are included in the deployment checklist discussed in the following sections.

Deployment Checklist

The product manager and the operations team should ensure that the solution meets the business requirements and standards determined during the Envisioning Phase. The checklist developed during the Planning Phase should contain the acceptance criteria that evaluate the performance of the solution. It should also provide a baseline for the customer to approve the solution. The following categories should be included in the checklist to test the solution before signoff:

  • Server

  • Database

  • Application (client and server side)

  • Additional considerations

These categories are discussed under the following headings.

Server

The following are some server-related items that should be considered for the checklist:

  • Have all relevant service packs been loaded to the production servers? Are the OS and installed service pack level well known and documented? You will need this information if the systems fail and manufacturer support is required.

  • Have the settings from the performance tuning in the test environment during the Stabilizing Phase been transferred correctly? At the same time, ensure that any configurations unique to the testing environment have not been transferred to the production environment.

  • Have backup power systems been fully tested to ensure proper operation?

  • Are an appropriate number of replacement hard disks on hand in case of failure in an array?

  • Are the default client connection network library settings established on the server?

  • Are all database and application server installation settings documented (such as sort orders and default language)?

  • Has communication between servers been checked to assure that proper DNS resolution and routing is functioning as expected?

  • Are alerts defined for key problems and conditions? Who monitors the e-mail address to which these are sent? Are pagers used? Has the alert system been tested?

  • Has the team removed guest accounts from the system and checked to ensure that this does not affect the application?

  • Is the appropriate level of directory security set?

  • Has security logging been implemented?

  • Have all non-essential services and open ports on the server been identified and closed?

  • Has the team tested production integration with third-party systems?

  • Have any and all event log messages been identified and investigated?

  • Does the OS have sufficient client access licenses for the expected peak traffic loads?

  • Are sufficient client access licenses and connections installed for the OS? Is this being monitored to assure that it does not reach its limit?

  • Are system configurations for all tiers backed up? Were scripts created to reset configurations in an emergency or to bring up a new server? Are they in a well-known location?

  • Have server backups been tested? Are procedures in place for proper storage and retrieval?

  • Have clustering software configuration and failover operations been tested?

Database

The following are some database-related items that should be considered for the checklist:

  • Have all database creation scripts been executed properly and without errors?

  • Were the database statistics updated before launch?

  • Have the database backups been tested to ensure that backup mechanisms are operating properly? Have restoration procedures been tested on the solution server and on different hardware to test failover procedures? Are off-site backup procedures in place?

  • Has database security been addressed and appropriate logon accounts created? Is the system administrator's (SA) account password blank? Are applications using the SA account or other account(s)?

  • Did the team define, test, schedule, and sign-off on maintenance plans?

  • Has a schedule been established for the transaction log dumping that will be sufficient to recover activity to the satisfaction of the business? Has it been tested?

  • Are sufficient client access licenses installed for the database server? Are these being monitored to assure that they do not reach their limit?

  • Has the latest build of the database from the development environment been migrated, installed, tested, and verified within the production environment?

  • The user databases should be checked to ensure that all the data from the database is transferred from the source solution to the target solution during deployment.

  • Has the database been loaded in the production environment with clean data, and have initial inventory levels been set? Have feeds from other systems been verified under load to ensure that system availability is unaffected at the time they run?

  • Is the database running on the default port of 1433? If so, can this be changed to another port or ports to enhance security of the application without affecting proper operation?

  • Are non-essential SQL Server services running (MS Search, OLAP)? Stop them if they are not required.

  • Are non-essential databases installed on the server? Remove databases such as pubs or Northwind, but be careful not to remove needed system databases such as model, tempdb, or master.

  • Is the database correctly tuned, and does it have the proper memory usage settings applied?

  • Is disk space sufficient for the expected size of the data 6-12 months ahead?

  • Have clustering software configuration and failover operations been tested with the databases?

Application (Client Side or Server Side)

The following list offers some client-side or server-side application-related items that should be considered for the checklist:

  • Are the proper security settings for the applications set and documented?

  • Has application logging been enabled or disabled, as required?

  • Has the golden release of the applications and other components been given a release number, archived, then deployed? Confirm that the golden release of the source code matches the version of the application that was released.

  • Are all required environmental settings for the applications set and documented?

  • Are all third-party software or components that are required by the system installed and documented (such as version numbers and vendor contact information)?

  • Ensure that the client application properly connects to the database. Perform cursory testing of the application that is not intrusive and does not change the production database. For example, running production reports is a good way to test database functionality without changing the live data.

  • Has connectivity between the middle-tier system and any back-end systems been tested under load? Has connection pooling been monitored to assure proper operation?

  • Are the activation types for any COM+ applications set properly? Has the application been tested with the consoles logged on and logged off to assure the proper identity is used?

  • Has the application integration been tested with third-party systems?

  • Have clustering software configuration and failover operations been tested with the applications?

Additional Considerations

Here are some additional considerations that could apply to your environment. Some of the tasks performed here are related to operations. Validating these tasks during deployment ensures operations is prepared to manage the solution and SLAs can be met.

  • Are scheduler jobs defined for common tasks? Jobs such as backups and health reporting are normally scheduled through a scheduler such as cron in UNIX. These may have been migrated over.

  • Has a disaster recovery plan (DRP) been established that includes database procedures? Who is the DRP team leader? Is the leader's contact information well known, and is a contingency leader appointed?

  • Has the team enabled change-control procedures for the operations environment?

  • Has the team finalized the operational processes and guidelines?

  • Has the team developed, tested, and simulated disaster recovery procedures?

  • Was an external connection used when testing the application against the operations system? The external connection should be similar to what a customer will use.

  • Was solution training delivered?

  • Is the processing speed acceptable?

  • Have the business objectives and requirements been met?

  • Have operation tests been performed? Steps should be taken to make sure that the operations team can properly track the servers and services with their monitoring tools.

Quiet Period

The quiet period for the target environment begins after stabilizing the deployed solution and continues until the deployment is complete. It usually exists for a period of 15 to 30 days. During this period, the operations team manages the deployed solution.

No significant changes should be made to the solution. However, a member from the project team may aid the operations team to manage and resolve problems that can affect the working of the deployed solution. This enables the organization to estimate the maintenance costs of the solution and prepare a budget. Changes made to the solution will be through the process of Change Management.

During the quiet period, the efficiency of the solution can be ascertained by evaluating the following:

  • Solution's stability

  • Solution's downtime

  • Maintenance required by the solution

Transferring Ownership to Operations

The final transition occurs when the project team completes its tasks and transfers the infrastructure, documentation, and operations to the Operations team. The ownership of the solution is also transferred to the Operations team.

The Operations team has to understand the functioning of the solution and manage it. The solution's documentation should supply information required to manage the solution.

The Operations team will require the following documents to handle the solution after migration:

  • User manual. The user manual details the procedures for working with the solution. It also details the procedures for installation and solution maintenance.

  • Hardware specifications. This document describes the hardware used in the production environment.

  • Software specifications. This document covers the different applications, such as third-party software used by the solution itself or used to stabilize the deployment. The software specifications also detail the different configurations and settings applied to the solution during or after the installation and deployment of the solution.

  • Support policies and procedures. This document details the updated business policies and procedures that need to be followed after the migration is complete.

Project Team Tasks

The project team will examine the deployment to ensure that all areas of the deployment are successfully completed and functioning as required. A final run of the tests that caused discrepancies can be used to check that they have been fixed. The project team ensures that:

  • All the procedures of the migration have been followed.

  • Backups are performed as required.

  • All security measures (hardware and software) are in place and operate without issues.

  • All errors and bugs are fixed.

  • Adequate training is provided to operations to manage the solution.

  • Different user accounts have been created and checked for their functionality.

Operations Team Tasks

The operations team will check the solution to ensure that it conforms to the business objectives. The operations team will:

  • Conduct a final run through of the solution to check its performance and stability.

  • Ensure that the project team has completed all the tasks needed to complete the deployment.

  • Check that the tools to perform routine tasks are set up.

  • Review the documentation.

  • Decide the frequency for performing routine tasks.

Conducting Project Review and Closure

After the deployment of the solution is complete, the team conducts a review meeting to assess the migration project. This review covers all the phases of the migration project, including the Envisioning, Planning, Developing, Stabilizing and Deploying Phases. By taking the time to discuss the entire migration project, important lessons can be learned and applied to future endeavors. This will also highlight the positive actions taken to successfully migrate the solution, and the less positive decisions or actions that delayed or hindered the migration. The project review can also compare the estimated outcome of the migration project with the actual targets achieved.

The customer sign-off signifies the end of the Deploying Phase. The solution's key stakeholders review the migrated solution and documentation and confirm that the needs of the project have been met. After this sign-off has been received, the project team can be disengaged. The exact terms of this sign off will depend on the migration requirements for the project.

Download

Get the Solution Guide for Migrating Oracle on UNIX to SQL Server on Windows

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions