<?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-mHGd7nm4EywKy0UPe9dZhg" name="02_04_execute_backout_plan,_FCK_gGzvEeCPgecPbK9bdg" guid="-mHGd7nm4EywKy0UPe9dZhg" changeDate="2012-05-30T14:08:13.096-0700" version="7.5.1">
  <mainDescription>Assuming a backout plan is available for this release, the deployment engineer (or development team) will follow the&#xD;
instructions for reversing the installation of the product into production, if there is a problem. While the plan might&#xD;
have been written with good intentions, sometimes key procedures are missing or have not been thought out. The team backing&#xD;
out the release should be aware that blindly following the backout plan might not be the best approach. It is best to&#xD;
consider the unique circumstances within which the deployment has failed and rely on common sense and experience when&#xD;
executing the backout plan.</mainDescription>
  <sections xmi:id="_IAD2c-B-EeC1y_NExchKwQ" name="Identify release problem(s)" guid="_IAD2c-B-EeC1y_NExchKwQ">
    <sectionDescription>&lt;p>&#xD;
    In the event that the release to production experiences problems, either during or after deployment, the backout plan&#xD;
    should be invoked. However, the deployment engineer (or development team) must understand where the release went wrong&#xD;
    so that the code can be fixed before the next release attempt. This is a critical step, but it should be done quickly&#xD;
    so that the problematic release can be reversed before significant damage is done to the production environment.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Log the issues as critical defects as soon as possible and assign those defects to the appropriate team members for&#xD;
    resolution.&#xD;
&lt;/p></sectionDescription>
  </sections>
  <sections xmi:id="_IAD2cOB-EeC1y_NExchKwQ" name="Backout the release" guid="_IAD2cOB-EeC1y_NExchKwQ">
    <sectionDescription>Following the instructions in the backout plan, reverse the deployment. However, be aware that the backout plan&#xD;
instructions are a guide and should not always be taken literally. This interpretation is due to the fact that not every&#xD;
problematic condition can be documented in advance and because each real-world situation might be slightly different.</sectionDescription>
  </sections>
  <sections xmi:id="_IAD2cuB-EeC1y_NExchKwQ" name="Determine if the backout was successful" guid="_IAD2cuB-EeC1y_NExchKwQ">
    <sectionDescription>Ascertain whether the reversal was successful. If not, key members of the release team, development team, or program level&#xD;
agile system team might need to be engaged to find and fix the problem(s).</sectionDescription>
  </sections>
  <sections xmi:id="_IAD2ceB-EeC1y_NExchKwQ" name="Communicate the backout" guid="_IAD2ceB-EeC1y_NExchKwQ">
    <sectionDescription>Ensure that all interested parties are aware of the failed release. Because releases often take place at odd hours to&#xD;
minimize end user impact, use beeper-based notifications judiciously. In most cases, an email to key stakeholders (such as&#xD;
the product owner and program manager) might suffice. Following up with a phone call also might be warranted.</sectionDescription>
  </sections>
  <purpose>The purpose of this task is to remove a specific release quickly and seamlessly from the production environment because the&#xD;
release has caused problems or because it has been determined by the stakeholder community as unfit for service.</purpose>
</org.eclipse.epf.uma:TaskDescription>