This documentation supports the 23.3 version of BMC Helix Change Management.To view an earlier version, select the version from the Product version menu.

Process flow of a release request

BMC Helix ITSM provides capabilities for planning, building, testing, and deploying controlled releases into your IT environment. 

Related topics

Learning-about-Release-Management

Initiating-and-modifying-a-release-request

The following image gives you an overview of the flow of the release request process. 

Milestones2.png


Release ticket lifecycle scenario

The following scenario helps you to understand the different stages in the lifecycle of a release ticket.

Calbro Services is a Houston-based IT company with over a thousand employees. The company uses basic printers to perform its print jobs. The IT team of Calbro Services plans to majorly upgrade their printing capabilities by deploying advanced printers that support Wi-Fi connectivity and an advanced print job management system.

The company has decided to track this upgrade as a release. Allen Allbrook is a release coordinator at Calbro Services in charge of this release. Let us see how Allen creates a release ticket from scratch, and manages the release lifecycle. 


Initiate

On the main Dashboard of BMC Helix ITSM, Allen selects Create New > Release. On the Create Release screen, he specifies the following details on the release profile:

  • In the General section, he enters Calbro Services as Company. He creates a release request without using a release template. Allen specifies the details of the release including the summary, impact, urgency, and business justification.

    Create Release_2.png

  • In the Release location section, he specifies the location, in this case, the Houston main office.
  • In the Assignment section, he selects the release coordinator group, and the release coordinator.
  • In the Dates section, he specifies the scheduled start and end dates.

  • In the Release plan section, he creates the following set of activities for each milestone:

    Milestone

    Activities

    Initiate

    • Identify all the existing printers.
    • Prepare a release plan for the upgrade

    Planning

    • Perform impact analysis of each change request and initiate approvals.
    • Plan for the integration of Wireless Gateway to the print server.
    • Prepare a rollback plan.
    • Identify documentation requirements for user manual.

    Build

    • Setup developer and testing (QA) environment for upgrading the printer.
    • Setup test automation suite.
    • Demo proof-of-concept for new printer upgrade in IT lab.

    Test

    • Perform printer server upgrade on QA environment.
    • Setup Wireless Gateway integration software in QA environment.
    • Run test automation.
    • Review and finalize the user guide.

    Deployment

    • Verify upgrade checklist based on milestones.
    • Publish the user guide.
    • Send broadcast to employees on how to use the advanced features of the new printers.
  • In the Risks section, Allen manually sets the risk to Risk Level 3.
  • In the Documents section, Allen attaches the technical specifications document of the advanced version of printers.
  • In the Work note section, Allen adds a note about the progress of the release mentioning @Carl so that Carl can see this note in his Dashboard. The work note can be made public. It appears on the Activity section once the release ticket is saved.

After specifying the necessary details, Allen submits the release ticket. The release is now in Draft status.

Allen works on the following two activities marked for the Initiate milestone:

  • The release plan is ready, so Allen marks it as completed.
  • Allen identifies the printers for upgrade and completes the activity of identifying all the existing printers.

Allen moves the release to the Initiation Approval status. All the IT Executive Management representatives assigned to review the release are notified about the review.

After the representatives approve the release, the release is moved to the Registered status. This status indicates that all the stakeholders agree to the release for upgrading the printers.


Planning

Allen moves the release to the Planning approval status. The approvers review the progress made so far, and approve it. The release is now in the In progress status. Allen does the following tasks:

  • Creates a change request for each printer, and relates them to the appropriate milestone.
  • Creates a change request for the printer servers to upgrade them to the latest version of the advanced features.
  • Creates a change request for the wireless gateway service to support integration with the printer servers.
  • Performs impact analysis of the change requests that he created and initiates their approval.

Allen has a team of five members to execute the change requests. He assigns them the role of change coordinator for the various change requests listed under the release plan. Next, Allen performs the following tasks:

  • Assigns the activity to document the user manual to Susan.
  • Updates the schedule dates of each change request.
  • Plans and creates an outage for each printer.
  • Indicates the downtime of each outage.


Build

After the release is planned, it is moved to the Build Approval status. The IT Executive Management representatives review the release via the CAB process, approves it, and then the release moves to In progress.

Along with his team of developers, testers, and change coordinators, Allen carries out the following activities:

  • Sets up developer and testing (QA) environments.
  • Develops the required utilities.
  • Builds the test automation suites, and tests them in the IT labs.

Allen also produces a proof-of-concept, and provides a demo of the upgrade process to the IT Executive Management representatives.


Test

Allen moves the release to the Test Approval status. The IT Executive Management representatives review the release via the CAB process, approve it, and then the release moves to the In progress status.

After receiving approval to test the upgrade, Allen and his team perform the following activities:

  • Roll out the upgrade tool on the QA environments.
  • Perform changes to printers in the QA lab.
  • Run test automation to confirm that the new features are available.

Along with the testing activities, they also perform the following tasks:

  • Troubleshoot errors found during testing, and resolve defects.
  • Review, validate, and finalize the user guide.


Deployment

Allen moves the release to the Deployment Approval status. After reviewing the test results, the IT Executive Management representatives approve deployment of the release. The release is now in the In progress status.

  • Allen rolls out the release according to the release plan.
  • As specified in the change requests, during the scheduled time, printers are upgraded with the advanced printers.
  • The printer server software is upgraded by using the tool that was built during the Build milestone.
  • Test automations are executed to verify that the rollout is successful.
  • A broadcast that contains a link to the new user guide is sent to help employees use the advanced features of the printer.

The release is rolled out to the business.


Close Down

Allen moves the release to the Close Down Approval status. The IT Executive Management representatives review whether the release was deployed according to plan, and provide their approval to close the release.

Allen's team members close the change requests, activities, and tasks that they have created. Allen moves the release to the Completed status, and sends out a survey to employees to get their feedback. He reviews the survey results to see whether any issues are reported. After confirming that the advanced printers are functioning properly, Allen moves the release to the Closed status.


Instructions for classic interfaces

View instructions for classic Smart IT

Release ticket lifecycle

Scenario

Calbro Services is a Houston-based IT company with over thousand employees. The company uses basic printers to perform their print jobs. The IT team of Calbro Services plans to do a major upgrade of their printing capabilities by deploying advanced printers that support Wi-Fi connectivity, in addition to an advanced print job management system.

The company has decided to track this upgrade as a release. In classic Smart IT, they have set the following milestones and statuses for the release lifecycle.

Release lifecycle.png

Allen Allbrook is a release coordinator at Calbro Services in charge of this release. The following scenario illustrates how Allen creates a release ticket from scratch, and manages the release lifecycle. 

  1. Initiate milestone

On the main Dashboard, Allen selects Create New > Release. On the Create Release screen, he creates a release request without using a release template. Allen selects Calbro Services in the Company list and specifies the following details on the release profile:

  • On the Basics tab, Allen specifies the details of the release including the scheduled start and end dates as well as the location, in this case, the Houston main office.
  • On the Release plan tab, he creates the following set of activities for each milestone:

Milestone table.png

  • On the Risks tab, Allen manually sets the risk to Risk Level 3.
  • On the Documents tab, Allen attaches the technical specifications document of the advanced version of printers.

After specifying the necessary details, Allen submits the release ticket. The release is now in Draft status.

Allen works on the following two activities marked for the Initiate milestone:

  • The release plan is ready, so Allen marks it as complete.
  • Allen identifies the printers for upgrade and completes the activity of identifying all the existing printers.

Allen moves the release to the Approval status. All the IT Executive Management representatives assigned to review the release are notified about the review.

After the representatives approve the release, the release is moved to the Registered status. This status indicates that all the stakeholders agree to the release for upgrading the printers.

2. Planning milestone

Allen moves the release to the Planning approval status. The approvers review the progress made so far, and approve it. The release is now in the In progress status. Allen does the following tasks:

  • Creates a change request for each printer, and relates them to the appropriate milestone.
  • Creates a change request for the printer servers to upgrade them to the latest version of the advanced features.
  • Creates a change request for the wireless gateway service to support integration with the printer servers.
  • Performs impact analysis of the change requests that he created and initiates their approval.

Allen has a team of five members to execute the change requests. He assigns them the role of change coordinator for the various change requests listed under the release plan. Next, Allen performs the following tasks:

  • Assigns the activity to document the user manual to Susan.
  • Updates the schedule dates of each change request.
  • Plans and creates an outage for each printer.
  • Indicates the downtime of each outage.

3. Build milestone

After the release is planned, it is moved to the Build Approval status. The IT Executive Management representatives review the release via the CAB process, approves it, and then the release moves to Build in progress.

Along with his team of developers, testers, and change coordinators, Allen carries out the following activities:

  • Sets up developer and testing (QA) environments.
  • Develops the required utilities.
  • Builds the test automation suites, and tests them in the IT labs.

Allen also produces a proof-of-concept, and provides a demo of the upgrade process to the IT Executive Management representatives.

4. Testing milestone

Allen moves the release to the Testing Approval status. The IT Executive Management representatives review the release via the CAB process, approve it, and then the release moves to the Testing in progress status.

After receiving approval to test the upgrade, Allen and his team perform the following activities:

  • Roll out the upgrade tool on the QA environments.
  • Perform changes to printers in the QA lab.
  • Run test automation to confirm that the new features are available.

Along with the testing activities, they also perform the following tasks:

  • Troubleshoot errors found during testing, and resolve defects.
  • Review, validate, and finalize the user guide.

5. Deployment milestone

Allen moves the release to the Deployment Approval status. After reviewing the test results, the IT Executive Management representatives approve deployment of the release. The release is now in the Deployment in progress status.

  • Allen rolls out the release according to the release plan.
  • As specified in the change requests, during the scheduled time, printers are upgraded with the advanced printers.
  • The printer server software is upgraded by using the tool that was built during the Build milestone.
  • Test automations are executed to verify that the rollout is successful.
  • A broadcast that contains a link to the new user guide is sent to help employees use the advanced features of the printer.

The release is rolled out to the business.

6. Close down milestone

Allen moves the release to the Close down Approval status. The IT Executive Management representatives review whether the release was deployed according to plan, and provide their approval to close the release.

Allen's team members close the change requests, activities, and tasks that they have created. Allen moves the release to the Close down Completed status, and sends out a survey to employees to get their feedback. He reviews the survey results to see whether any issues are reported. After confirming that the advanced printers are functioning properly, Allen moves the release to the Close down Closed status.

View instructions for Mid Tier

To build the release

After a release request is approved at the Build Approval phase, you must work the release through the Build milestone. This milestone assembles the CIs that are needed to create the release package in a controlled IT environment before it goes into service. You also add change requests and activities to the release. At most companies, the Build milestone is interchangeable with the Test milestone. The Build and Test milestones are typically iterative processes. Release candidates are built, tested, and frequently kicked back so that they can be fixed. During the Build milestone, you complete change requests, and activities to build, and test the release package, add additional change requests and activities to fix bugs and add additional functionality to the release.

Important

For release coordinators, the Build milestone is mostly a manual stage to verify that the Build process is successful. You must use the Release form to update information, revise your plans, add additional change requests and activities, and so on.

  1. Open the release request at the Build In Progress status.
  2. (Optional) On the Dates/System tab, revise the start and end dates as needed.
  3. (Optional) On the Manifest tab, add changes or activities to the release as needed.
  4. Click Rollup to accumulate the risk level, costs, and time spent from the related change requests (displayed on the Manifest tab).
  5. Click Save.
  6. Use the Process Status Flow to move the release request from the Build In Progress status to the Test Approval phase. 
    The release must be approved before it can move forward.

To test the release

After a release request is approved at the Test Approval phase, you must test it at the Test milestone before you can release it. Testers can be business staff, users, or other IT staff. Once they verify the release, you can roll it out.

Important

For release coordinators, the Test milestone is mostly a manual stage to verify that the service work is successful in a controlled environment. You must use the Release form to update information, revise your plans, add additional change requests, and activities. In most companies, the Test milestone is interchangeable with the Build milestone.


  1. Open the release request at the Test In Progress status.
  2. Revise the start and end dates as needed.
  3. Add changes or activities to the release as needed.
  4. Click Rollup to accumulate the risk level, costs, and time spent from the related change requests (displayed on the Manifest tab).
  5. Save your changes.
  6. Use the Process Status Flow area to move the release request from the Test In Progress status to the Deployment Approval phase.

To deploy the release

After a release request is approved at the Deployment Approval phase, the release is rolled out to the business at the Deployment milestone. Deploy the release to the IT infrastructure according to the prepared plan at the scheduled start date (for example, over a long holiday weekend). You must distribute hardware and software to the installation site. Task implementers must follow a prepared script of tasks and activities to complete the installation. The Deployment milestone can require approvals to make sure the release does not need to be rolled back.

  1. Open the release request at the Deployment In Progress status.
  2. On the Dates/System tab, revise the deployment start and end dates, if required.
    Use these date fields to specify when the release is deployed to the IT infrastructure. These dates are usually different from the Scheduled Start Date and Scheduled End Date, which is typically a longer process.
  3. On the Manifest tab, review the status of the change requests and activities that are included in the release manifest.
  4. (Optional) Use the Schedule Assist tool to search for available deployment times for the release request.
    The Schedule Assist tool identifies possible conflicts associated with releases and windows of opportunity that your release request can be scheduled around. These deployment dates are based on global business events and CI availability. For more information, see Initiating a release.
  5. Click Rollup to accumulate the risk level, costs, and time spent from the related change requests (displayed on the Manifest tab).
  6. Click Save.
  7. When all the change requests and activities reach Closed status, use the Process Status Flow to move the release request from the Deployment In Progress status to the Close Down Approval phase. 

To close down the release

After the release request is approved at the Close Down Approval phase, you cannot close the release request until all tasks are closed, whether due to success, cancellation, or failure. When all the tasks related to a release request are closed, the requester and the release coordinator are notified that the release is resolved.

  1. Open the release request at the Close Down In Progress status.
  2. Revise the start and end dates, as required.
  3. Add changes or activities to the release, as required.
  4. Click Rollup to accumulate the risk level, costs, and time spent from the related change requests (displayed on the Manifest tab).
  5. Save your changes.
  6. Click Next in the Process Flow Status bar to move the release request forward.

After the release is closed, users with Release Master permissions can update information within the change record. They cannot add new manifests or ad hoc approvers. They also cannot update the following fields:

  • Business Justification
  • Impact
  • Urgency
  • Priority
  • Risk Level
  • Release Type
  • All date

To cancel a release

After the release moves into the Planning milestone, it can be cancelled. Cancelling a release will close the release record and move it to the Close Down milestone. All changes and activities created or related to the release must be Completed, Cancelled, or Closed to cancel the release request.

  1. Open the release request.
  2. For the current milestone, select Cancel > Reason. 
    Reason can have the following values:
    • No Longer Required
    • Funding Not Available
    • To Be Re-Scheduled
    • Resources Not Available

If all related changes and activities defined in the Manifest tab are Completed, Cancelled, or Closed, the status of the release request is changed to Cancelled, with the status reason as the reason selected and the release request is moved to the Close Down milestone.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*