About the Release Package Process App

The Release Package process app includes two applications: Release Package and Deployment Path. Each has a single workflow.

The Release Package application is described in this topic.
The Deployment Path application is described in About the Deployment Path Application.

Participants:

Release Managers
Package Creators
Release Engineers

Release Packages follow a process organized into these stages:

Define

The first stage of the Release Package is the definition stage.

While the release package is in the Define stage, release engineers can:

Select release type, which limits the deployment paths available for the release package.
Add deployment tasks. These can be newly-created tasks specific to the release package or tasks copied from task templates and other release packages. Deployment tasks can be added, reordered, or deleted as needed as the release package is deployed through the deployment path.
View and associate requests and deployment units.

Once accepted, the release package moves to the Deliver stage.

Deliver

In the Deliver stage, the release packages are deployed.

Accepted release packages move to the Ready to Deploy state.
Once the deployment is started, deployment tasks initiate the related deployment processes and deploy any deployment units.
Once all deployment tasks are complete, the release package moves to the Deployed state. If any deployment tasks fail, the release package is sent to the Deployment Error state. Failed release packages can be retried or returned to development for more work.
Successful deployments move to the Verification stage.

Verification

In the Verification stage, the functionality implemented by the release packages is verified.

Deployed release packages move to the Environment QA state to be verified.
If issues are found during the verification, the release package can be transitioned as follows:
- If functional changes are needed:
  Sent back to the Define stage for fixes to be made to the deployment units
- 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 release package, and the environment is not locked, you can fix any problems and then redeploy, using different deployment units 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 release package 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 release package has been successfully deployed, but the functionality of the release package has been tested and failed. Retry is used if the release package did not successfully deploy.
If no issues are found during the verification, and if there are additional environments pending in the deployment path, the release package moves to the next environment. Otherwise, it moves to the Completed state. In Completed status, a release package can still be associated with a release train. Once the cycle of the release package is completely done, the release engineer or release manager can move it to Closed.