| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription 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="-3MMugrRt4H5NPnZe38OAjA" |
| name=",_Dq0GQAIoEdyLh7vsrHZ4YA" guid="-3MMugrRt4H5NPnZe38OAjA" changeDate="2007-05-28T11:31:33.068-0700"> |
| <sections xmi:id="_xVY94A06EdyKD8XBf_Hbrw" name="Integrate implemented elements" |
| guid="_xVY94A06EdyKD8XBf_Hbrw"> |
| <sectionDescription><p>
 |
| In&nbsp;the relevant&nbsp;<a class="elementLink" href="./../../openup/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>, combine all completed&nbsp;<a class="elementLink" href="./../../openup/guidances/concepts/change_set_430BF233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that are
 |
| not in the latest baseline. Resolve any conflicting versions of the artifacts by either removing one of the change sets
 |
| that created the conflict&nbsp;or by creating a new change set that includes merged versions of the conflicting
 |
| artifacts.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_hbwWQA07EdyKD8XBf_Hbrw" name="Create build" guid="_hbwWQA07EdyKD8XBf_Hbrw"> |
| <sectionDescription><p>
 |
| 
 |
| Create the build.&nbsp;The details of this step depend upon the implementation language and development environment and
 |
| 
 |
| may involve compiling and linking (in the case of compiled languages) and/or other processes that result in an
 |
| 
 |
| executable increment of the system.
 |
| 
 |
| </p>
 |
| 
 |
| <p>
 |
| 
 |
| Examples of these steps&nbsp;include:
 |
| 
 |
| </p>
 |
| 
 |
| <ol>
 |
| 
 |
| <li>
 |
| 
 |
| Compiling and linking the source artifacts to create an executable
 |
| 
 |
| </li>
 |
| 
 |
| <li>
 |
| 
 |
| Loading binary objects on a test bench or simulator
 |
| 
 |
| </li>
 |
| 
 |
| <li>
 |
| 
 |
| Running a script to load/update database schemas
 |
| 
 |
| </li>
 |
| 
 |
| <li>
 |
| 
 |
| Packaging and deploying web applications<br />
 |
| 
 |
| </li>
 |
| 
 |
| </ol></sectionDescription> |
| </sections> |
| <sections xmi:id="_S5vB0A08EdyKD8XBf_Hbrw" name="Test integrated elements" guid="_S5vB0A08EdyKD8XBf_Hbrw"> |
| <sectionDescription><p>
 |
| 
 |
| <a class="elementLink" href="./../../openup/tasks/run_developer_tests_73D7DBC4.html" guid="_0iYCUMlgEdmt3adZL5Dmdw">Run Developer Tests</a>&nbsp;against the integrated elements to verify that they behave the same as they did in isolation.
 |
| 
 |
| Ensure that the scope of these&nbsp;tests is as broad as possible, which ensures that the latest change sets did not
 |
| 
 |
| cause failing developer tests in other areas of the system.
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_Dm_bEA09EdyKD8XBf_Hbrw" name="Make changes available" guid="_Dm_bEA09EdyKD8XBf_Hbrw"> |
| <sectionDescription><p>
 |
| 
 |
| When tests are successfully completed and the build is considered "good," the results&nbsp;are made available to the
 |
| 
 |
| rest of the team by <a class="elementLink" href="./../../openup/guidances/guidelines/promoting_changes_9087B764.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Promoting Changes</a>.&nbsp;The details of this step depend on the configuration
 |
| 
 |
| management tools in use, but in general this involves committing&nbsp;a tested change set to the CM repository so that
 |
| 
 |
| it&nbsp;serves as the basis of development for the next increment of the system.&nbsp; This is the essence of <a class="elementLink" href="./../../openup/guidances/concepts/continuous_integration_87682D06.html" guid="_B3xkEPD0EdqYgerqi84oCA">Continuous Integration</a>.
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_1yKnAA1BEdyKD8XBf_Hbrw" name="Run "Smoke Tests"" guid="_1yKnAA1BEdyKD8XBf_Hbrw"> |
| <sectionDescription><p>
 |
| 
 |
| Several builds will be created in each iteration. For each build, this step is performed only when change sets have
 |
| 
 |
| been delivered to satisfy the requirements of that build.
 |
| 
 |
| </p>
 |
| 
 |
| <p>
 |
| 
 |
| Execute a sub-set of the system tests to ensure that the build is suitable prior to committing resources to the full
 |
| 
 |
| scope of system testing.&nbsp;While the level of testing will vary, focus on gaining confidence that the increment is
 |
| 
 |
| of sufficient quality to establish a baseline for system testing.
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_Vf5kEA1CEdyKD8XBf_Hbrw" name="Create a baseline" guid="_Vf5kEA1CEdyKD8XBf_Hbrw"> |
| <sectionDescription><p>
 |
| 
 |
| Several builds will be created in each iteration. For each build, this step is performed only when change sets have
 |
| 
 |
| been delivered to satisfy the requirements of that build.
 |
| 
 |
| </p>
 |
| 
 |
| <p>
 |
| 
 |
| The&nbsp;procedure for this step depends on the&nbsp;configuration management tools in use.
 |
| 
 |
| </p>
 |
| 
 |
| <p>
 |
| 
 |
| Create a baseline that unambiguously identifies the configuration for the build that is ready for system testing.
 |
| 
 |
| Identify the version of each implementation element and supporting artifacts that were used to create&nbsp;this build.
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <keyConsiderations><p>
 |
| 
 |
| In order to be effective at applying the practice of <a class="elementLink" href="./../../openup/guidances/concepts/continuous_integration_87682D06.html" guid="_B3xkEPD0EdqYgerqi84oCA">Continuous Integration</a>,&nbsp;the time to integrate, build, and test the increment must be short enough that it can be
 |
| 
 |
| performed several times per day.&nbsp; Changes should be broken down into relatively small <a class="elementLink" href="./../../openup/guidances/concepts/change_set_430BF233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that can
 |
| 
 |
| be implemented, integrated and tested quickly.
 |
| 
 |
| </p></keyConsiderations> |
| <purpose>The purpose of this task is to integrate all changes made by all developers into the code base and perform the minimal
 |
| 
 |
| 
 |
| testing on the system increment in order to validate the build.&nbsp; The goal is to identify integration issues as soon as
 |
| 
 |
| 
 |
| possible so they can be corrected easily by the right person, at the right time.</purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
