| <?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><p> |
| During iterative software development the team will create numerous <a class="elementLink" |
| href="./../../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" |
| guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>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. |
| </p> |
| <p> |
| As a build progresses from development towards production it is beneficial to know two characteristics: |
| </p> |
| <p> |
| <strong>Build contents</strong> – identifying the elements and their versions |
| </p> |
| <ul> |
| <li> |
| What is in this build (completed work items) |
| </li> |
| <li> |
| What is partially in this build (work items that are partially complete) |
| </li> |
| <li> |
| What is 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 that has been completed.&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 work items |
| </li> |
| <li> |
| A build is generated clearly identifying the&nbsp;changes |
| </li> |
| <li> |
| Testing is conducted |
| </li> |
| <li> |
| When testing is successful the changes are delivered to the next&nbsp;verification level |
| </li> |
| </ul> |
| <p> |
| Ultimately all required testing is complete and the a new system version is ready. |
| </p> |
| <p> |
| It can also be beneficial to isolate work being performed at the different stages using different <a |
| class="elementLink" href="./../../../openup_basic/guidances/concepts/workspace,_0cEmAMlgEdmt3adZL5Dmdw.html" |
| guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>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. |
| </p> |
| <p> |
| A promotional 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 build passes the |
| previous stage. For example you would not commit the resources to&nbsp;System Testing&nbsp;a build until it passes |
| integration tests. |
| </li> |
| <li> |
| Helps to ensure that a build 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 build (Integration Tested build, for example) |
| in relative isolation from destabilizing changes from other developers |
| </li> |
| </ol></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |