| <?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_basic\guidances\guidelines\promoting_builds.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_builds.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_SM4YIL6dEdqti4GwqTkbsQ CRC: 495951481 -->Promoting Builds<!-- END:presentationName,_SM4YIL6dEdqti4GwqTkbsQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_SM4YIL6dEdqti4GwqTkbsQ CRC: 471641791 -->This guideline describes how to migrate a build 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: 3467665125 --><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. 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 changes |
| </li> |
| <li> |
| Testing is conducted |
| </li> |
| <li> |
| When testing is successful the changes are delivered to the next 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 System Testing 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><!-- END:mainDescription,-zCM2ucJJxc_bQr_LoHlSaQ --> |
| </body> |
| </html> |