| <?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
 |
| instructions for reversing the installation of the product into production, if there is a problem. While the plan might
 |
| have been written with good intentions, sometimes key procedures are missing or have not been thought out. The team backing
 |
| out the release should be aware that blindly following the backout plan might not be the best approach. It is best to
 |
| consider the unique circumstances within which the deployment has failed and rely on common sense and experience when
 |
| executing the backout plan.</mainDescription> |
| <sections xmi:id="_IAD2c-B-EeC1y_NExchKwQ" name="Identify release problem(s)" guid="_IAD2c-B-EeC1y_NExchKwQ"> |
| <sectionDescription><p>
 |
| %EOL% In the event that the release to production experiences problems, either during or after deployment, the backout
 |
| plan%EOL% should be invoked. However, the deployment engineer (or development team) must understand where the release
 |
| went wrong%EOL% so that the code can be fixed before the next release attempt. This is a critical step, but it should
 |
| be done quickly%EOL% so that the problematic release can be reversed before significant damage is done to the
 |
| production environment.%EOL%
 |
| </p>%EOL%
 |
| <p>
 |
| %EOL% Log the issues as critical defects as soon as possible and assign those defects to the appropriate team members
 |
| for%EOL% resolution.%EOL%
 |
| </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%EOL%instructions are a guide and should not always be taken literally. This interpretation is due to the fact that not
 |
| every%EOL%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%EOL%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
 |
| minimize end user impact, use beeper-based notifications judiciously. In most cases, an email to key stakeholders (such as
 |
| 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
 |
| release has caused problems or because it has been determined by the stakeholder community as unfit for service.</purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
