| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>openup&#92;guidances&#92;guidelines&#92;&#92;promoting_changes.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: promoting_changes.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_SM4YIL6dEdqti4GwqTkbsQ CRC: 2941393720 -->Promoting Changes<!-- END:presentationName,_SM4YIL6dEdqti4GwqTkbsQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_SM4YIL6dEdqti4GwqTkbsQ CRC: 3950184017 -->This guideline describes how to promote a set of related changes up through a set of tiers from a private development area to a release area.<!-- END:briefDescription,_SM4YIL6dEdqti4GwqTkbsQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-zCM2ucJJxc_bQr_LoHlSaQ CRC: 1567451693 --><p> |
| During iterative software development, the team 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> – 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 changes are partially in this build (work items that are partially complete) |
| </li> |
| <li> |
| What changes are 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. 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 <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 changes included in the build |
| </li> |
| <li> |
| Testing is conducted |
| </li> |
| <li> |
| When testing is successful the changes are marked with the appropriate verification level through labeling, |
| baselining or other related techniques. |
| </li> |
| </ul> |
| <p> |
| Ultimately all required testing is complete and a new system increment is ready. |
| </p> |
| <p> |
| Separate <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 set of changes, makes the context for the tests stable, 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 changes passes the |
| previous stage. For example you would not commit the resources to system testing a build until it |
| passes developer tests. |
| </li> |
| <li> |
| Helps to ensure that a change 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 set of changes 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><!-- END:mainDescription,-zCM2ucJJxc_bQr_LoHlSaQ --> |
| </body> |
| </html> |
