OpenUP/OpenUP_SP/library/openup_basic/guidances/guidelines/promoting_builds.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.3/uma.ecore" epf:version="1.0.0" xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ" name="promoting_builds,_SM4YIL6dEdqti4GwqTkbsQ" guid="-zCM2ucJJxc_bQr_LoHlSaQ" changeDate="2007-02-26T13:49:04.018-0500" version="1.0.0">
  <mainDescription>&lt;p&gt;
    During iterative software development the team will create numerous &lt;a class=&quot;elementLink&quot;
    href=&quot;./../../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html&quot;
    guid=&quot;_0YuXEMlgEdmt3adZL5Dmdw&quot;&gt;Build&lt;/a&gt;s. A build is initiated by combining the work completed by one or more
    developers and resolving any conflicts that are encountered. 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&gt;
&lt;p&gt;
    As a build progresses from development towards production it is beneficial to know two characteristics:
&lt;/p&gt;
&lt;p&gt;
    &lt;strong&gt;Build contents&lt;/strong&gt; – identifying the elements and their versions
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        What is in this build (completed work items)
    &lt;/li&gt;
    &lt;li&gt;
        What is partially in this build (work items that are partially complete)
    &lt;/li&gt;
    &lt;li&gt;
        What is not in this build (work items that are not reflected at all in this build)
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    &lt;strong&gt;Verification Level&lt;/strong&gt; – identifying what amount of testing that has been completed.&amp;nbsp; For example,
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Unit Tested
    &lt;/li&gt;
    &lt;li&gt;
        Integration Tested
    &lt;/li&gt;
    &lt;li&gt;
        System Tested
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
    the following steps:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Changes are introduced into the system in the form of completed work items
    &lt;/li&gt;
    &lt;li&gt;
        A build is generated clearly identifying the&amp;nbsp;changes
    &lt;/li&gt;
    &lt;li&gt;
        Testing is conducted
    &lt;/li&gt;
    &lt;li&gt;
        When testing is successful the changes are delivered to the next&amp;nbsp;verification level
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    Ultimately all required testing is complete and the a new system version is ready.
&lt;/p&gt;
&lt;p&gt;
    It can also be beneficial to isolate work being performed at the different stages using different &lt;a
    class=&quot;elementLink&quot; href=&quot;./../../../openup_basic/guidances/concepts/workspace,_0cEmAMlgEdmt3adZL5Dmdw.html&quot;
    guid=&quot;_0cEmAMlgEdmt3adZL5Dmdw&quot;&gt;Workspace&lt;/a&gt;s. This ensures that the effort of testing a build is applied to the
    correct version and also allows developers to continue working on the next build while the previous build is being
    tested.
&lt;/p&gt;
&lt;p&gt;
    A promotional lifecycle such as this offers three key benefits
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        Reduces effort because there is no reason to execute the tests in the next stages until the build passes the
        previous stage. For example you would not commit the resources to&amp;nbsp;System Testing&amp;nbsp;a build until it passes
        integration tests.
    &lt;/li&gt;
    &lt;li&gt;
        Helps to ensure that a build which is moved into production has been subjected to the appropriate level of testing
        first.
    &lt;/li&gt;
    &lt;li&gt;
        Simplifies debugging since developers can base their work on a proven build (Integration Tested build, for example)
        in relative isolation from destabilizing changes from other developers
    &lt;/li&gt;
&lt;/ol&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>