Building a controlled environment for 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.

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. For more information, see Testing-the-release.

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 Release-Management-overview. 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.