Initiating and modifying a release request

To initiate a release request

1. On the BMC Helix ITSM menu bar, select Create New > Release.
   The Create Release page is displayed.
2. In the Use a Template section, select the company for which you are creating the release request. 
   If you have created release requests for the same company by using release templates and have not cleared the browser cache, the most recently used release templates created for that company are displayed.
3. Select a template and click Continue.
   • On the Basics tab, specify details such as release description, categories, scheduled start and end dates, release location, and so on. Some fields are populated automatically from the template.
   • On the Release Plan tab, you can add multiple milestones, relate existing change requests, and create activities for each milestone.
   • On the Risks tab, you can manually select a risk level, or apply the highest risk of the change request that you relate with the release request on the release plan.
   • On the Documents tab, to attach supporting documents, select the type of document that you want to attach, and then attach the file.
     You can attach three files to a document type at one time.
4. Click Submit Release. 
   The release request is created. The coordinator of the release gets an update about the release request that you created.
   
   

To modify the release request

You can modify the release request to make the following changes to the release:

• Change the scheduled dates
• Change or add the actual dates
• Change the status of the release request
• Change the assignment

1. Open the change request.
2. Click Edit.
3. Make the required changes.
4. Click Save.

To assign release request

Release coordinators create the release request assignments, which can be assigned manually or automatically. Assigned release requests can also be listed in the Release Information table in the console. Release requests are assigned automatically on creation by the Release Management application. The assignment is based on the release request's categorization. For more information, see Automatic request assignment.

1. Open the release request.
2. Click Edit.
   
   
3. Select Assign to me to assign the release request to yourself.
4. (Optional) Select any of the following fields:
   1. Auto-assign to the best fit group—The release is assigned automatically according to the release request categorization.
   2. Support Company, Support Organization, and Support group—The release is assigned to the selected support company, organization, or group respectively.
   3. Search—Enter the name and select the required person to assign the release that person.
5. Click Assign.

Release risk level

You can select one of the following options to set the risk of release requests:

• Select risk level manually: Select a risk level ranging from 1 to 5.
• Calculate from the highest risk Change Request: The highest risk of the change request that you relate in the release plan is applied to the release request. You must edit the Risks section and select the Calculate from the highest risk Change Request option for the system to increment the risk level when you relate change requests with the highest risk level. The following example explains how this option works.

To plan and schedule the release request

1. Open the release request.
2. Click Edit.
   
   

3. Enter the date in Scheduled Dates, Deployment Dates.
   The following table describes the dates in the release request:

   Field	Description
   Scheduled Start Date	Enter the date and time at which the release implementation is scheduled to start (the moment at which the release is planned to be set to the status Work in Progress).
   Scheduled End Date	Enter the date and time at which the release implementation is scheduled to be completed (the moment at which the release is planned to be set to the status Closed). Important: Scheduled start date and end date values cannot be modified when the release is awaiting approval.
   Deployment Start Date	Enter the date when the release starts to be deployed to the IT infrastructure.
   Deployment End Date	Enter the date when the release finishes deployment to the IT infrastructure.
   Actual Start Date	Enter the date for when work started on the release.
   Actual End Date	Enter the date for when work ended for the release.
   Target Date	Enter the date by when the release must be completed, according to the applicable service level target. Alternatively, the target date can be a date that is agreed to on an ad hoc basis, per release. On the Date/System tab, this field is read-only and is automatically set to the target date and time selected on the release form.

4. Click Save.

To initiate a release 

1. Review the request for changes (RFCs) to make sure you understand their requirements.
   Perform this manual step before you open Release Management. Make sure you understand the scheduled start and end dates, the CIs involved, the manifests necessary to complete the release, the CAB approvers, and so on.

   Best practice
   Enter information into Release Management as soon as it is available to you. You can revise it at later milestones.

2. On the Release Management Console, click Create to open the Release form.
   The Release ID field is filled automatically with an ID number for the release request.
   In the Initiate stage, the release request initially appears in Draft status.
3. Use the following fields to specify the release coordinator:
   • Coordinator Group—Specify the group of people with the Release Coordinator functional role. This list is populated with groups that have at least one user with a Release Coordinator functional role.
   • Coordinator—Specify the user responsible for the release. The list is populated with people with the Release Coordinator functional role and who are included in the selected Coordinator Group.

4. From the Service field, select the business service configuration item (CI) that relates to the release request that you are creating.
   The Service field relates business service configuration items (CIs) to the release request at the time it is created. 

   Important

   The business service CI is not a physical CI (such as a printer or a router); it is a logical CI. In this context, a logical CI is a business service that can be provided from one business or organization within a business, to another. Service CIs can include customer support, employee provisioning, web farms, and storage. When business service CIs are created and made available on the Service field menu, they are either related directly to the customer or related to the customer's company, organization, or department. If you need to have a new business service CI added to the Service field menu, you must notify a system administrator with Asset Administrator privileges.

5. (Optional) Select a template to complete a part of the release request.
   Release templates are especially useful in any release request that follows well-defined methods for specific and repeated requirements. Release templates do more than simply fill out fields for you; they can also include CIs and manifests to the release request. The template is attached to the release request.

   Important

   The release template can be applied in the Draft state, that is, while creating the release request.

   If you start to enter fields in the release request and then select a release template, the release template overwrites any field values that are already present in the release request. Any relationships or manifests included with the release request are not overwritten. Any additional manifests from the template are added as peers, and additional relationships (for example, CIs) are included with the release request.

6. (Optional) Specify the target date as the date by when the release must be completed, according to the applicable service level target or specify the target date that is agreed to on an ad hoc basis.

7. Complete the following fields:

   Field	Description
   Summary	Provide a brief description of the release.
   Business Justification	Specify the business requirement for the request. Select an option based on the policies defined by your company. These values are for informational purpose only. You have the following options: Corporate Strategic Business Unit Strategic Maintenance Defect Upgrade Enhancement Customer Commitment Sarbanes-Oxley
   Impact	Specify the extent to which the release affects the business. The default value is 4-Minor/Localized. Impact is often directly related to the extent to which the service has degraded from the agreed service levels. Impact can be measured by the number of people affected, the criticality of the affected system, and the loss of revenue as a result of the service degradation or disruption.
   Urgency	Specify a value that indicates the importance of the release request, and reflects how quickly a release must be implemented, or the time available to reduce the impact of the release on the business. The default value is Low. Use the following factors to determine Impact and Urgency: Number of customers affected by associated releases. Duration and scope of the service disruption. Availability of a solution or workaround. Type of service being disrupted, usually based on the involved CI. Awareness of the future impact on the business.
   Priority	(Optional) Specify the importance that you (as support staff) assign to the release request. Priority indicates the relative order in which to address the releases. It is influenced by considerations of risk and resource availability, but is primarily driven by the combination of Urgency and Impact. The default value is Low.

8. Select the Risk Level to indicate the relative risk associated with the release.
   The default risk level is Level 1, which is the lowest level. The highest risk level is Level 5. The Risk Level is used as a criteria to determine the required approvals.
   For more information about how to configure or modify the Impact, Urgency, and Priority data so that it is set automatically, see Computing-risk-levels.

9. Select the Release Type to further categorize the release request.

   Option	Description
   Full	All components of the release are built, tested, and deployed together. You can use the Full release type if you want to make sure that the release or version of your application, plus the necessary CI components to run the application, are all linked throughout the entire process.
   Delta	This option includes only incremental releases and only those components or CIs that need to be included in this release. You can use the Delta release type if your application is moving from version 1.0.00 to 1.1.00, for example.
   Package	All individual Full and Delta releases are grouped together to form a packaged release. You can use the Package release type to you combine several minor and major updates together.
   Backlog	This option identifies and reviews multiple changes, incidents, and problems that are candidates to target the release implementation. The Backlog release type is a grouping mechanism that the CAB uses as their candidates to review the future releases.

   Important

   Do not manually set the Milestone, Status, and Status Reason fields in the Release form.
   When you use the Process Flow Status bar to move the release request to the next milestone, the value in the Status field automatically changes, based on the options you select from the Status bar menus.

10. Click Save to create the release request.
    This information is the minimum information needed to create the release.

To specify the business justification

At the Initiate milestone, the release coordinator prepares a business case to justify the release, for example, compliance with Sarbanes-Oxley requirements or fixing a defect in a mission-critical server.

Release coordinators specify the business justification of the release to initiate the implementation of the release and to decide on corrective actions (if needed). If there is not enough funding to implement the release, you should create a contingency plan in case an adjusted business case for the release can still get the necessary approvals. If you cannot get your business case approved, you must inform the requesters of the release that the business case for the release has been rejected.

1. Open the release request.
2. Enter information in the Business Justification field on the Release form.
3. Select a Business Justification to indicate the business reason for implementing the release request.
   Business justification information is important when the request goes through the approval process. Use this information to make sure that the necessary funding is available to implement the release.
4. Click the Categorization tab and complete the appropriate fields to categorize the release request.
   The application automatically assigns the release request to the submitter if they have the functional role of a release coordinator when the request is saved. Assignments are determined by the rules configured by the application administrator.

5. To create or relate other items to the release request, click the Relationships tab.
   You can create and relate release requests to your current release request before it is saved. You can also create and relate configuration items, change requests, and so on, to the release request.

   Important

   If you close the new release without saving, the new items are not saved. There is no relationship between these new items and the release request because the release request was not created.

6. Click Save.
   Depending on the settings configured by your application administrator, you might see the Release form in Modify mode. You might also have to open the Release form in Search mode and query for your request.

To plan and schedule the release request

1. Open the release request at the Planning In Progress status.
2. Open the Calendar.
3. Select Quick Action > View Calendar.
4. Select how many days of requests and business events to display.
5. Select Release Requests to view the release requests in the calendar.
6. Select the requests and business events for a specific day. 
7. Close the Change Calendar.
   For more information, see Scheduling-changes-by-using-the-Calendar.
8. Register available or unavailable time segments for your business event, operational categorization, or CI.
   For more information, see Managing-time-segment-availability-based-on-business-event-or-operational-category.
9. Click the Date/System tab. 
   
   
   When planning a release request, you use this tab to track the scheduled, actual, and deployment start and end dates of releases.
10. Revise the start and end dates.
11. Review the Business Justification field on the Release form.
12. (Optional) Select Links > Financials.
    You can calculate the costs associated with the change request.
13. Click Save.
14. Use the Process Status Flow to move the release request from the Planning In Progress status to the Build Approval phase.
    The release must be approved before it can move forward.

To schedule the end and start date of a release

For the Initiate milestone, in the Release form, use the Date/System tab to add the scheduled start and end dates for the release. These dates can also be revised for the Planning milestone. During deployment, use this tab to track the actual and deployment start and end dates for the release.

The following information describes each of these date fields on the Release form:

You can use the Schedule Assist tool to identify possible conflicts associated with releases. You can search for windows of opportunity that your release request can be scheduled around. The Schedule Assist tool helps you search for available deployment times for the release request based on global business events and CI availability. When you create a release request that modifies a CI, for example, you must upgrade a server, you can schedule a time segment for the CI that shows it is unavailable to the rest of the support staff. If another member of the support staff wants that CI to be available, they should schedule their own release in a different time segment.

To build the release

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

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.
   The release must be approved before it can move forward. 

To deploy the release to the business

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.
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. 
   The release must be approved before it can move forward. 

To close down the release

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.

To register unique business events for releases

1. In the navigation pane of the Release form, select Advanced > Time Segments > Business Event.
2. On the Search Business Event/Location Definition dialog box, click New.
3. On the Business Event/Location Definition dialog box, define a unique time segment for the business event or categorization and click Save.
4. Click Add to create a time segment.
5. In the Description field on the Business Time Segment dialog box, enter a description for the time segment.
6. In the Availability field, select Available or Unavailable.
7. In the Level field, select a level of 10 or higher.
8. In the Duration Type field, select One time (which generates a single occurrence of the time segment) or Recurring (which cannot span multiple days, but must be scheduled within a 24-hour period).
9. Enter the starting and ending dates and times for the duration of the time segment.
10. Click Save, and then click Finish.

For more information, see the following topics:

• Registering-time-segments-in-Change-Management
• Managing-time-segment-availability-based-on-business-event-or-operational-category
• Registering-time-segments-in-Change-Management

To register CI time segments for releases

1. In the navigation pane of the Release form, select Advanced > Time Segments > Configuration Item (CI).
2. In the CI Advanced Search form, enter the information necessary to search for a CI and then click Search.
3. From the search results, select a CI.
4. Click Explore CI to view a CI and its relationship in a tree structure and select the CI.
5. In the Registration for Shared Time Segment dialog box, click Add.
6. In the Description field on the Business Time Segment dialog box, enter a description for the time segment.
7. In the Availability field, select Available or Unavailable.
8. In the Level field, select a level of 10 or higher.
9. In the Duration Type field, select One time (which generates a single occurrence of the time segment) or Recurring (which cannot span multiple days, but must be scheduled within a 24-hour period). If you select Recurring, you must specify the recurrence.
10. Enter the starting and ending dates and times for the duration of the time segment.
11. Click Save to associate the time segment to the CI, and then click Finish.

For more information, see the following topics:

• Registering-time-segments-in-Change-Management
• Managing-a-CI-blackout-schedule-with-time-segments
• Registering-time-segments-in-Change-Management

To use Schedule Assist to search for available times

1. Open the release request.
2. Click the Dates tab.
3. Click the Schedule Assist icon.
4. Define any time segments needed for the CIs.
5. Click Find Next Available Time.
6. Click Schedule Time Segment.
7. On the Associate Time Segment to CIs dialog box, use the following steps to associate CIs to time segments.
   1. Select the CI to associate the time segment to.
   2. Enter a description of the time segment.
   3. Click Create Time Segment and click Next.
8. Enter the scheduled start date and end date and click Next.
9. Save the change request.

To assign release requests

The release coordinator is typically responsible for the overall release process.

1. Open the release request.
   Certain fields are automatically filled based on the default configuration and requester information in the release request. For example, the Release Coordinator field already has an assignment.
2. To assign a release coordinator, select the appropriate option:
   • Coordinator Group—Provides a list of coordinator groups. Select the group of the release coordinator that you want to assign the release to.
     Groups that have at least one user with the Release Coordinator functional role are listed for selection.
   • Release Coordinator—Provides a list of users with the functional role of a Release Coordinator in the selected coordinator group. Select the appropriate release coordinator from this list.
3. Click Save.
   The release coordinator is automatically notified of the assignment.

To add cost to the release request

Risk, time, and costs (actual and budget) from activities and change requests that are related to the release manifest are rolled up on the Financials tab. For activities, only the time spent, and the actual and budget costs, are rolled up to the release. For change requests, in addition to time spent and costs, the highest Risk Level is also rolled up to the release.

1. Open the release request.

2. Click Links > Financials.

   

   Based on the changes and activities displayed in the release manifest, the Release Costs table displays the costs associated with the release, and the rolled-up costs from the related activities or change requests. 
   For more information, see To create a release manifest.

3. Click Add to attach costs to the release.

   Important

   If you attach a cost entry to the release, the Release Costs table does not list a related request ID.

4. Filter the release costs by selecting values from the Cost Category field. 
   The default option displays all entries. Select Infrastructure Change, Release, or Activity to display costs associated with those entries.
5. Filter the release costs by selecting values from the Show field. 
   All Cost Types (the default value) displays all release and rolled-up costs.

6. (Optional) Click View to view the costs associated with the release, or click Delete to remove them.

   Important

   You can only delete Release costs from the Financials page of the Release form.

7. Click Save.

To use quick actions

The Quick Actions menu on the Manifest tab enables you to perform advanced actions on changes and activities. Not all actions are available with all request types.

This table shows the relationship between request types and the available actions you can perform on them.

1. Select the entry from the Relationships table.

2. From the Quick Actions menu, select an action.
   For example, you can copy relationships from a CI that is already related to the release request. The following table lists all the quick actions that you can use: 

   Relationship action	Effect
   Update Attributes	Opens the Manifest Attributes dialog box for updating the milestone attributes for the relationship.
   Get Related Relationships	Copies the relationships of the selected record to the release request's relationships. For more information, see Managing-relationships-between-requests-and-other-records.

3. Click Execute.

To add or modify work information to a release request

You might need to modify a release request with work history entries that you add during its life cycle, in order to document activities performed or information gathered. For example, you can track a release request's progress in the work history by recording the steps that you took to implement it.

Use the Work Details tab to add work information about activities performed for the current release request.

The request must still follow the stages in the recommended life cycle of a release request, as described in Learning-about-Release-Management. The Process Flow Status bar directs you with messages if there are fields that must be filled in when you move to a new milestone.

Add the following work information:

• General Information—Notes about the record; for example, you might want to add a note that a particular CI was deployed, and include the date.
• Planning—Notes about a plan to implement a global release throughout your organization.
• Implementation—Installation and backout procedures for the release.
• Costing and Charging—Additional information about the cost of the current CI, incident, change, or so on. For example, you can add a note that the cost of maintaining a CI was split between two cost centers, or that the cost to implement a release came under budget.

Any user with release related permissions, such as User, Master, or Viewer can add or modify work info from the Release Management console or the release request in Modify mode. However, only users with Release Master permissions can add work info to closed release requests.

1. Open the release request.
2. To add new work information, under the Add Work Info details section on the Work Detail tab, enter the following information:
   • Notes—Enter the details of your work information record in this field.
   • Attachment—Add any attachments related to the work information.
3. Click More Details to select the work information type and add any additional attachments.
4. From the Work Info Type list, select the type of work information to add.
5. In the Attachment fields, add any additional attachments (up to three) required for the work information.
6. When you finish updating the release request, under Add Work Info click Save.
   The entry is added to the work history.
7. To view or update the entries in the work information, select the work info record and click View. 
8. Under the Edit Work Info section:
   1. Update the required fields.
   2. To delete an attachment, click the delete icon for that attachment.
   3. Click Save.
9. To view a report of selected activities that you performed against this request, select the records from the work info table and click Report.
10. Click History, to view the history of when and by whom each of the work information was added.
11. Click Save.