Managing and optimizing the application release workflow

This topic explains the general procedure you might use to define your application release workflow, including plans, plan templates, plan stages, tickets, plan runs, requests, procedures, and steps.

Before you begin

• Plan your release life cycle. Consider the following stages:
  
  • Development
  • Quality assurance (QA)
  • User acceptance
  • Deployment to production
• Ensure the integration of all external systems that you are planning to use such as as build server, bug tracking system, test management system, and other.
• Configure your application, topology and infrastructure.

High-level steps for managing the application release workflow

1. Create the release plan template, and then add the necessary stages that match your release life cycle.
   With plans, you can specify the sequence of stages that your application goes through during the release life cycle.  For example, you might have the following stages: development > performance testing > regression testing > pre-release testing > user acceptance > deployment to production. You can create a new plan only from the plan template.
2. From the plan template, create a new plan instance. You can assign a release manager and a team to the plan.
3. Add application routes to the plan.
   Routes, determine the environments that you access on different stages of your plan. For more information about routes, see Managing-routes.
4. Create tickets for the plan.
   With tickets, you can add specific information about the current state of the application or its components within a plan. You can integrate tickets with the external tracking systems such as Rally, Jira, BMC Remedy IT Service Management, and others and reference tickets to the specific user stories or defects.. For more information, see Managing-tickets.
5. Create requests for the plan and associate tickets with requests.
   A request describes the work to be done in the deployment process, such as putting an application in an environment, adding attributes, and packaging and deploying the software. A request is composed of steps, which can be manual (for example, “Check logs for errors”) or automated (for example, “Deploy package”) using one of the automation modules. For more information about requests, see Managing-requests.
   
   1. Create requests.
   2. Add steps to requests.
      A step is an individual and complete part of a request. Steps indicate the way a request is executed. A step includes components and automation scripts assigned to the application that you are dealing with. For more information about steps, see Managing-steps.
   3. (Optional) Associate tickets to the request steps.
   4. (Optional) Combine steps into procedures.
      A procedure is a reusable set of steps which you can use in multiple requests. With procedures,  you can set conditions that depend on the property or the runtime phase for a particular step or set conditions that depend on the environment or the environment type for the whole request. For more information about procedures, see Managing-procedures.
   5. (Optional) Combine requests into projects.
6. Group requests and projects into runs within stages.
   A run is a group of requests in a plan stage. With runs, you can to assemble requests from different applications and different target environments into an executable flow and promote a run from one stage to another.
7. Promote runs to the next stage.
8. Promote through stages till the end of the release plan.

Related topics

Managing-plans

Managing-projects

Managing-plan-runs

Managing-tickets

Managing-requests