The Release Planning and Deployment stage begins upon completion of software testing. During this time, no changes to the software are permitted excepting those explicitly directed by the Customer. Release Planning and Deployment is performed in three phases: Pre-deployment, Deployment, and Post-deployment


The Pre-Deployment Phase addresses three major tasks simultaneously:

  • Release Planning
  • Training and Documentation
  • User Acceptance Testing (UAT)

In most cases, software deployments to the System Users will be transparent to end users.

However, careful release planning and coordination is essential for ensuring that the Customer is consulted on all new or altered code and the decision to release it. Release planning also includes identification of active and standby resources, as well as specification of a roll-back strategy in the event it becomes necessary to revert or roll back the deployed code.

Partnet will collaborate with the Customer and any associated Change Control Board (CCB) representatives to create a release deployment plan, to include:

  • A cutover schedule, identifying the date and time for the release.
  • A listing of the features and/or problem reports that will be contained in the release.
  • Identification of a release coordinator.
  • A release impact assessment, including impacts to integration partners.
  • A roll-back plan, outlining a contingency process for removing new changes should it become necessary.

The following tasks can then be performed as part of the pre-deployment phase:

  • Identify the deployment team, including: Release Project Manager, Change/Configuration Manager, Database Administrator, Technical Lead, Software Test Engineer, End User Tester
  • Prepare a draft deployment schedule which:
    • Chronologically outlines required deployment tasks and estimates, including tasks to be performed by external third parties.
    • Identifies the complexity, timeframe, and task owner of each deployment task.
  • Execute a mock deployment on the Staging environment, which allows the team to rehearse deployment tasks and validate estimates.
  • Execute the roll-back plan on the Staging environment which allows the team to rehearse the roll-back strategy and make adjustments as necessary.
  • Document any issues and new risks identified during the mock deployment.
  • Document any issue/risk mitigation strategies.
  • Finalize the deployment schedule.

Training and Documentation

If there are major changes to a system or if we are developing a new system, Partnet will develop a comprehensive training plan prior to deployment—and all major releases to follow— for each of the affected user groups. Partnet’s training plan will identify:

  • Major functional areas where training is required.
  • End-user groups working within identified functional areas.
  • A list of required jobs aids.
  • References to COTS training materials and user guides.
  • Schedules and preliminary agendas for remote and onsite training sessions (upon request).

User Acceptance Testing(UAT)

UAT will occur following the mock deployment to the Staging environment. UAT concludes with deployment of the application to Production, or as defined by the Customer. Partnet supports UAT via onsite or remote workshops. In either case, the following process will be used to monitor and assess defects discovered during UAT:

  • UAT participants identify and report potential defects to the Customer.
  • The Customer assesses the relevance of the reported defect.
  • If relevant, the PMO creates a ticket in an issue-tracking system.
  • Partnet responds with an initial defect assessment, including estimated level of effort and associated risks. All defect assessments will be provided within one business day.
  • Team Partnet consults with the Customer on the resolution approach.


The deployment phase begins after a GO decision is given by the Customer and Configuration Management team. The GO decision signifies approval of the new software to be deployed and the scheduled deployment date and time. Partnet’s deployment processes allow software changes to be transparently deployed—i.e., without system downtime—to any environments when data schema changes allow. If the system has a clustered environment, Partnet configuration Managers will use IT automation tools to avoid taking down the entire clustered environment during a release.

Automation allows each server to be individually upgraded and restarted while other servers in the cluster continue to operate. Load balancing appliances continue to direct web requests to the remaining nodes in the cluster. This process is repeated until all of the nodes are updated transparent deployments may not possible in cases where software or database schema changes create incompatibilities between the clustered nodes. In these cases, Partnet employs automated migration processes to minimize system downtime to whatever time is minimally required to execute schema changes in the database and migrate the associated data.

Deployment Process

Partnet always attempts to automate the provisioning and deployment of the software solution. This will standardize the deployment environments and improve the quality of each release as more automation is introduced.

Automation scripts are used to provision all the necessary software libraries and tools. These are configured to execute the correct sequence for each release iteration.  Repetitive tasks are automated using these scripts, resulting in:

  • Reduced labor associated with manual configuration.
  • Increased consistency across environments.

Push commands are used to trigger modifications quickly. Configuration files tailor the task modules required by each server or group of servers. Configurations are used to manage and setup multiple server platforms, distributions, storage and switching applications. By simplifying deployment processes, the Solution will have the ability to respond more readily to changing customer needs.

Release Coordination

During the deployment, the Partnet Release Project Manager will coordinate with internal resources and external third parties to ensure tasks are executed according to the deployment schedule. The Release Project Manager will also be responsible for communicating to the broader deployment team as key milestones are reached, or in the event of unplanned complications.

Partnet will provide the Customer with a release communication plan. The communication plan elaborates on the scheduled and ad-hoc communication techniques to be employed during the release, including scheduled teleconferences, group email lists, chat rooms, and instant messaging.

Common milestones in the deployment schedule will include:

  • Deployment of code to a single node
  • Customer and Partnet testing
  • Deployment of code to the next node if applicable

Post deployment, the Partnet’s sustainment staff will closely monitor the deployed solution to assess its performance and functional capability upon release.  Automated monitoring modules will also be used to assess system health.

Once a release is complete, Partnet will package and provide the any remaining documentation associated with the release to the customer. This completes the software development cycle.

I hope that you have enjoyed Part 5 of our Blog Series, the Importance of a Defined Software Development Life Cycle. If you have missed any parts of the series, check them out at