| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-zT8t7LcbcrgIhYd_XUi6DA" name="01_review_conform_to_release_controls,_PwLDcDHMEeC7j_IRiP-WPQ" guid="-zT8t7LcbcrgIhYd_XUi6DA" changeDate="2012-05-30T14:22:34.002-0700" version="7.5.1"> |
| <mainDescription><p>
 |
| Release controls describe the minimum number of requirements that a software package must adhere to before being
 |
| released into production. This is especially important if a development team is new or emerging, because they might not
 |
| be aware of the great responsibilities a deployment manager has. In fact, a deployment manager is responsible to senior
 |
| management for ensuring that nothing is placed into production that does not conform to the rigid controls designed to
 |
| protect the IT organization's ability to successfully deliver IT services to internal and external customers.
 |
| </p>
 |
| <p>
 |
| Release controls typically consist of:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Release or deployment plan
 |
| </li>
 |
| <li>
 |
| Backout plan
 |
| </li>
 |
| <li>
 |
| Release component definitions
 |
| </li>
 |
| <li>
 |
| Release package integrity verification
 |
| </li>
 |
| <li>
 |
| References to configuration items (CIs)
 |
| </li>
 |
| <li>
 |
| Customer approval
 |
| </li>
 |
| <li>
 |
| Ready for transfer to operations and support staff
 |
| </li>
 |
| </ul></mainDescription> |
| <sections xmi:id="_IAJWAuB-EeC1y_NExchKwQ" name="Locate release controls" guid="_IAJWAuB-EeC1y_NExchKwQ"> |
| <sectionDescription>If the program%sq%s release controls are not readily available, the development team must engage the deployment manager and/or%EOL%their deployment engineers to know where to find the release controls and be able to comply with them.</sectionDescription> |
| </sections> |
| <sections xmi:id="_IAJWAeB-EeC1y_NExchKwQ" name="Review release controls" guid="_IAJWAeB-EeC1y_NExchKwQ"> |
| <sectionDescription>The development team should thoroughly review the release controls so that it understands what is expected before a release%EOL%is accepted into the production environment. If the team has any questions or issues with the controls, team members should%EOL%communicate directly with the deployment manager or the deployment engineer to understand the issues.</sectionDescription> |
| </sections> |
| <sections xmi:id="_IAJWAOB-EeC1y_NExchKwQ" name="Ensure the team release conforms to the controls" guid="_IAJWAOB-EeC1y_NExchKwQ"> |
| <sectionDescription><p>
 |
| Coordinated releases at the program level are very formal processes. They are formal for a very good reason - namely,
 |
| the company's production environment could be corrupted and serious business ramifications could result, including:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Lost revenue
 |
| </li>
 |
| <li>
 |
| customer dissatisfaction
 |
| </li>
 |
| <li>
 |
| Fines resulting from legal noncompliance
 |
| </li>
 |
| <li>
 |
| Lost employee productivity
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| All development team members that contribute to a release are expected to adhere to all the controls defined at the
 |
| program level. Non-compliance could result in multiple impacts:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The entire release being abandoned, which could lead to customer or end user dissatisfaction
 |
| </li>
 |
| <li>
 |
| The results of multiple feature development Sprint/Iterations not being included in the release
 |
| </li>
 |
| <li>
 |
| Embarrassment on the part of the development team member that did not comply
 |
| </li>
 |
| <li>
 |
| Loss of funding for that development team
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <purpose>The purpose of this task is to ensure that there are no (or minimal) negative impacts to existing production systems,
 |
| products, services, and operations.</purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
