blob: 919bafaadf20fdb62a3bfdf20ef7738e0a2ea62b [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" xmlns:rmc="" rmc:version="7.5.1" xmlns: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">
%EOL% In the event that the release to production experiences problems, either during or after deployment, the backout&#xD;
plan%EOL% should be invoked. However, the deployment engineer (or development team) must understand where the release&#xD;
went wrong%EOL% so that the code can be fixed before the next release attempt. This is a critical step, but it should&#xD;
be done quickly%EOL% so that the problematic release can be reversed before significant damage is done to the&#xD;
production environment.%EOL%&#xD;
%EOL% Log the issues as critical defects as soon as possible and assign those defects to the appropriate team members&#xD;
for%EOL% resolution.%EOL%&#xD;
<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&#xD;
plan%EOL%instructions are a guide and should not always be taken literally. This interpretation is due to the fact that not&#xD;
every%EOL%problematic condition can be documented in advance and because each real-world situation might be slightly&#xD;
<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&#xD;
level%EOL%agile system team might need to be engaged to find and fix the problem(s).</sectionDescription>
<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>
<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>