<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ"
    name="promoting_changes,_SM4YIL6dEdqti4GwqTkbsQ" guid="-zCM2ucJJxc_bQr_LoHlSaQ"
    changeDate="2007-08-04T04:54:07.000-0700" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    During iterative software development, the team&amp;nbsp;creates numerous &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html&quot; guid=&quot;_1QU9MAIoEdyLh7vsrHZ4YA&quot;>Change Set&lt;/a>s that are combined into a &lt;a class=&quot;elementLink&quot; href=&quot;./../../../practice.tech.continuous_integration.base/workproducts/build_95D7D8FD.html&quot; guid=&quot;_0YuXEMlgEdmt3adZL5Dmdw&quot;>Build&lt;/a>. A build is initiated by combining the work completed by one or more&#xD;
    developers and resolving any conflicts between those changes. Ideally a build is then subjected to a battery of tests&#xD;
    to determine if it is of sufficient quality to move into production.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    As the changes progress from development towards production, its beneficial to know two characteristics:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Test Context&lt;/strong>&amp;nbsp;– identifying the elements and their versions that are tested together&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        What changes are in this build (completed work items)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What&amp;nbsp;changes are&amp;nbsp;partially in this build (work items that are partially complete)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What changes are&amp;nbsp;not in this build (work items that are not reflected at all in this build)&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    &lt;strong>Verification Level&lt;/strong> – identifying what amount of testing is complete.&amp;nbsp; For example,&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Unit Tested&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Integration Tested&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        System Tested&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of&#xD;
    the following steps:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Changes are introduced into the system in the form of completed&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html&quot; guid=&quot;_1QU9MAIoEdyLh7vsrHZ4YA&quot;>Change Set&lt;/a>s&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A build is generated clearly identifying the&amp;nbsp;changes included in the build&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Testing is conducted&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When testing is successful the changes are marked with the appropriate&amp;nbsp;verification level through labeling,&#xD;
        baselining or other related techniques.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Ultimately all required testing is complete and a new system&amp;nbsp;increment is ready.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Separate&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html&quot; guid=&quot;_0cEmAMlgEdmt3adZL5Dmdw&quot;>Workspace&lt;/a>s are often used as the context for each level of testing. As changes are&#xD;
    added to the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html&quot; guid=&quot;_0cEmAMlgEdmt3adZL5Dmdw&quot;>Workspace&lt;/a>, it is verified for consistency and tested. This ensures that the effort&#xD;
    of testing a build is applied to the correct&amp;nbsp;set of changes, makes the context for the tests stable,&amp;nbsp;and also&#xD;
    allows developers to continue working on the next build while the tests are being conducted.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A change promotion lifecycle such as this offers three key benefits&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Reduces effort because there is no reason to execute the tests in the next stages until the&amp;nbsp;changes passes the&#xD;
        previous stage. For example you would not commit the resources to&amp;nbsp;system testing a build until it&#xD;
        passes&amp;nbsp;developer tests.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Helps to ensure that a change&amp;nbsp;which is moved into production has been subjected to the appropriate level of&#xD;
        testing first.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Simplifies debugging since developers can base their work on a proven&amp;nbsp;set of changes&amp;nbsp;in relative&#xD;
        isolation from destabilizing changes from other developers&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    For an example of this approach see &lt;a href=&quot;http://www.agiledata.org/essays/sandboxes.html&quot; target=&quot;_blank&quot;>Development Sandboxes: An Agile &quot;Best&quot; Practice.&lt;/a>&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>