Creating a release request at the initiate milestone - Best Practice  view

You can create a release request at the Initiate stage when using the Best Practice view of Release Management.

To create a release request at the Initiate milestone

1. Review the RFCs to make sure you understand their requirements.
    This is a manual step you should perform before you open Release Management. You should understand the scheduled start and end dates, the CIs involved, the manifests necessary to complete the release, the CAB approvers, and so on.

   Information

   Recommendation

   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 automatically filled with an ID number for the release request.
    In the Initiate stage, the release request initially appears in Draft status. The release request has not yet been submitted to the Release Management process.
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 Coordinator Group selected.

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. Business service CIs are related either to the customer directly or to the customer's company, organization, or department.

   Warning

   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, storage, and so on. When business service CIs are created and made available on the Service field menu, they are related either to a customer directly or 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 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. For more information, see Selecting-release-templates. The template is attached to the release request.

   Warning

   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) The target date is 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.

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. By default 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 agreed service levels. Impact can be measured by the number of people affected, the criticality of the system affected, 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 The type of service being disrupted, usually based on the CI involved 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 criterion to determine 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 for the release request.
    You use this field to further categorize the releases that are released into the IT infrastructure.

   Option	Description
   Full	All components of the release are built, tested and deployed together. You typically 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	Includes only incremental releases and only those components or CIs that need to be included in this release. You typically use the Delta release type if your application was moving from version 1.0.00 to 1.1.00.
   Package	All individual Full and Delta releases are grouped together and form a packaged release. You typically use the Package release type if you combine several minor and major updates together.
   Backlog	Method to identify and review multiple changes, incidents, and problems that are candidates to target to implement in a release. The Backlog release type is a grouping mechanism that the CAB uses as their candidates to review for future releases.

   Warning

   Important

   Do not manually set the Milestone, Status, and Status Reason fields in the Release form.
   When you use the Process Flow Status bar 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 is the minimum information needed to create the release.