| <?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: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-06-14T07:46:11.002-0700" version="1.0.0"> |
| <mainDescription><p>
 |
| During iterative software development, the team&nbsp;creates numerous <a class="elementLink" href="./../../../openup/guidances/concepts/change_set_430BF233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that
 |
| are combined into a <a class="elementLink" href="./../../../openup/workproducts/build_95D7D8FD.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</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.
 |
| </p>
 |
| <p>
 |
| As the changes progress from development towards production, its beneficial to know two characteristics:
 |
| </p>
 |
| <p>
 |
| <strong>Test Context</strong>&nbsp;– identifying the elements and their versions that are tested together
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| What changes are in this build (completed work items)
 |
| </li>
 |
| <li>
 |
| What&nbsp;changes are&nbsp;partially in this build (work items that are partially complete)
 |
| </li>
 |
| <li>
 |
| What changes are&nbsp;not in this build (work items that are not reflected at all in this build)
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| <strong>Verification Level</strong> – identifying what amount of testing is complete.&nbsp; For example,
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Unit Tested
 |
| </li>
 |
| <li>
 |
| Integration Tested
 |
| </li>
 |
| <li>
 |
| System Tested
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
 |
| the following steps:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Changes are introduced into the system in the form of completed&nbsp;<a class="elementLink" href="./../../../openup/guidances/concepts/change_set_430BF233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s
 |
| </li>
 |
| <li>
 |
| A build is generated clearly identifying the&nbsp;changes included in the build
 |
| </li>
 |
| <li>
 |
| Testing is conducted
 |
| </li>
 |
| <li>
 |
| When testing is successful the changes are marked with the appropriate&nbsp;verification level through labeling,
 |
| baselining or other related techniques.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Ultimately all required testing is complete and a new system&nbsp;increment is ready.
 |
| </p>
 |
| <p>
 |
| Separate&nbsp;<a class="elementLink" href="./../../../openup/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>s are often used as the context for each level of testing. As changes are
 |
| added to the <a class="elementLink" href="./../../../openup/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>, it is verified for consistency and tested. This ensures that the effort
 |
| of testing a build is applied to the correct&nbsp;set of changes, makes the context for the tests stable,&nbsp;and also
 |
| allows developers to continue working on the next build while the tests are being conducted.
 |
| </p>
 |
| <p>
 |
| A change promotion lifecycle such as this offers three key benefits
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| Reduces effort because there is no reason to execute the tests in the next stages until the&nbsp;changes passes the
 |
| previous stage. For example you would not commit the resources to&nbsp;system testing a build until it
 |
| passes&nbsp;developer tests.
 |
| </li>
 |
| <li>
 |
| Helps to ensure that a change&nbsp;which is moved into production has been subjected to the appropriate level of
 |
| testing first.
 |
| </li>
 |
| <li>
 |
| Simplifies debugging since developers can base their work on a proven&nbsp;set of changes&nbsp;in relative
 |
| isolation from destabilizing changes from other developers
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| For an example of this approach see <a href="http://www.agiledata.org/essays/sandboxes.html" target="_blank">Development Sandboxes: An Agile "Best" Practice.</a>
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |