About Turnovers

The Turnover process app includes Turnover and Deployment Path applications. Typically, developers create turnovers. Turnovers can be created when the application release is in the Executing workflow state.

Turnovers follow a process organized into these stages:

Define

The first stage of the Turnover is the definition stage.

Participants:

Developers
Release Engineers
Release Managers

While the turnover is in the Define stage, developers or release engineers can:

Select release type, which limits the deployment paths available for the turnover.
Add deployment tasks. These can be newly created tasks specific to the turnover or tasks copied from runbooks and other turnovers. Deployment tasks can be added, reordered, or deleted as needed as the turnover is deployed through the deployment path.
View and associate business requests and development tasks, limited in selection by the application releases associated with the turnover. These requests and tasks are considered to be complete and can be viewed by clicking the Show Delivered link on the Requirements/Development tab for a release train or application release.
Create component versions and select component versions and snapshots associated with the turnover.
Download component versions to view them locally.

Once the turnover is defined, it is sent to a release engineer for acceptance. Once accepted, the turnover moves to the Deliver phase.

Deliver

In the Deliver stage, the turnovers are deployed.

Participants:

Release Engineers

Accepted turnovers move to the Ready to Deploy state.

Once a release engineer starts the deployment, any manual deployment tasks are automatically submitted in the designated SBM project and automation deployment tasks initiate the related Release Automation processes. Manual tasks must be completed by the SBM item owners; automated tasks are completed through associated Release Automation processes.

Once all tasks are complete, the turnover moves to the Deployed state. If any manual or automated tasks fail to deploy, the turnover is sent to the Deployment Error state. Failed turnovers can be retried or returned to development for more work.

Successful deployments move to the Verification phase.

Verification

In the Verification stage, the functionality implemented by the turnovers is verified.

Participants:

Release Engineers

Deployed turnovers move to the Environment QA state to be verified.

If issues are found during the verification, the turnover can be transitioned as follows:

If functional changes are needed:
Sent back to the Construction stage for fixes to be made to the component versions
If changes are needed to deployment tasks or the environment configuration:
Redeployed to the same environment for further verification after those changes are made

If redeploy is allowed for the turnover, and the environment is not locked, you can fix any problems and then redeploy, using different component versions as needed. For example, this would typically be when QA is testing software and opening issues for Development to fix in the pre-release testing cycle. This would continue until you want the turnover to proceed to the final environments, such as pre-production staging and production.

Note: Redeploy is different from retry in that redeploy is used after the turnover has been successfully deployed, but the functionality of the turnover has been tested and failed. Retry is used if the turnover did not successfully deploy.

If no issues are found during the verification, and if there are additional environments pending in the deployment path, the turnover moves to the next environment. Otherwise, it moves to the Completed state and is closed.

Related Topics

Configuring and Deploying Turnovers