praclib/temp/practice.tech.continuous_integration.base/guidances/guidelines/promoting_changes.xmi

<?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.4/uma.ecore"
    xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.2.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.2.0" xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ"
    name="promoting_changes,_SM4YIL6dEdqti4GwqTkbsQ" guid="-zCM2ucJJxc_bQr_LoHlSaQ"
    changeDate="2007-08-04T07:54:07.000-0400" version="1.0.0">
  <mainDescription>&lt;p>
    During iterative software development, the team&amp;nbsp;creates numerous &lt;a class=&quot;elementLink&quot;
    href=&quot;./resources/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;./../../../opn.swd.prac.legacy_impl/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
    developers and resolving any conflicts between those changes. Ideally a build is then subjected to a battery of tests
    to determine if it is of sufficient quality to move into production.
&lt;/p>
&lt;p>
    As the changes progress from development towards production, its beneficial to know two characteristics:
&lt;/p>
&lt;p>
    &lt;strong>Test Context&lt;/strong>&amp;nbsp;– identifying the elements and their versions that are tested together
&lt;/p>
&lt;ul>
    &lt;li>
        What changes are in this build (completed work items)
    &lt;/li>
    &lt;li>
        What&amp;nbsp;changes are&amp;nbsp;partially in this build (work items that are partially complete)
    &lt;/li>
    &lt;li>
        What changes are&amp;nbsp;not in this build (work items that are not reflected at all in this build)
    &lt;/li>
&lt;/ul>
&lt;p>
    &lt;strong>Verification Level&lt;/strong> – identifying what amount of testing is complete.&amp;nbsp; For example,
&lt;/p>
&lt;ul>
    &lt;li>
        Unit Tested
    &lt;/li>
    &lt;li>
        Integration Tested
    &lt;/li>
    &lt;li>
        System Tested
    &lt;/li>
&lt;/ul>
&lt;p>
    The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
    the following steps:
&lt;/p>
&lt;ul>
    &lt;li>
        Changes are introduced into the system in the form of completed&amp;nbsp;&lt;a class=&quot;elementLink&quot;
        href=&quot;./resources/change_set_430BF233.html&quot; guid=&quot;_1QU9MAIoEdyLh7vsrHZ4YA&quot;>Change Set&lt;/a>s
    &lt;/li>
    &lt;li>
        A build is generated clearly identifying the&amp;nbsp;changes included in the build
    &lt;/li>
    &lt;li>
        Testing is conducted
    &lt;/li>
    &lt;li>
        When testing is successful the changes are marked with the appropriate&amp;nbsp;verification level through labeling,
        baselining or other related techniques.
    &lt;/li>
&lt;/ul>
&lt;p>
    Ultimately all required testing is complete and a new system&amp;nbsp;increment is ready.
&lt;/p>
&lt;p>
    Separate&amp;nbsp;&lt;a class=&quot;elementLink&quot;
    href=&quot;./../../../opn.swd.prac.legacy_pm/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
    added to the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../opn.swd.prac.legacy_pm/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
    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
    allows developers to continue working on the next build while the tests are being conducted.
&lt;/p>
&lt;p>
    A change promotion lifecycle such as this offers three key benefits
&lt;/p>
&lt;ol>
    &lt;li>
        Reduces effort because there is no reason to execute the tests in the next stages until the&amp;nbsp;changes passes the
        previous stage. For example you would not commit the resources to&amp;nbsp;system testing a build until it
        passes&amp;nbsp;developer tests.
    &lt;/li>
    &lt;li>
        Helps to ensure that a change&amp;nbsp;which is moved into production has been subjected to the appropriate level of
        testing first.
    &lt;/li>
    &lt;li>
        Simplifies debugging since developers can base their work on a proven&amp;nbsp;set of changes&amp;nbsp;in relative
        isolation from destabilizing changes from other developers
    &lt;/li>
&lt;/ol>
&lt;p>
    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>
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>