| <?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="-DlaqJu4sEqMPk84qhJ6IEA" |
| name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA" |
| changeDate="2007-07-18T05:02:20.454-0700"> |
| <mainDescription><p>
 |
| Continuous integration is a software development practice that completely rebuilds and tests the application frequently
 |
| -- ideally, every time a change is introduced. This approach provides many benefits as outlined in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/continuous_integration_87682D06.html" guid="_B3xkEPD0EdqYgerqi84oCA">Concept: Continuous Integration</a> and in <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#WIKP-CI" guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
 |
| </p>
 |
| <h3>
 |
| Basic steps
 |
| </h3>
 |
| <p>
 |
| The detailed application of continuous integration depends on which tools you use (configuration management system,
 |
| automated build tool, automated test tool, and so forth). However, these are the basic steps:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| A developer, let’s call her Jane, selects a&nbsp;work item&nbsp;to work on.
 |
| </li>
 |
| <li>
 |
| Jane updates her <a class="elementLink" href="./../../../openup/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> to include the most recent <a class="elementLink" href="./../../../openup/workproducts/implementation_917CA61E.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> from
 |
| the integration workspace.
 |
| </li>
 |
| <li>
 |
| Jane makes her changes in her workspace to both her developer tests and to the implementation, and then she tests
 |
| the changes.
 |
| </li>
 |
| <li>
 |
| Before committing the changes, Jane updates her workspace again (because other developers may have introduced
 |
| conflicting changes) and reruns her developer tests.
 |
| </li>
 |
| <li>
 |
| If these tests are successful, the changes are promoted (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/promoting_changes_9087B764.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: Promoting Changes</a>) to&nbsp;the&nbsp;integration workspace.
 |
| </li>
 |
| <li>
 |
| A complete <a class="elementLink" href="./../../../openup/workproducts/build_95D7D8FD.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a> of the application is performed by using the implementation from the
 |
| integration workspace, and the entire suite of developer tests is run on this build.
 |
| </li>
 |
| <li>
 |
| If any of these tests fail, the team is notified, and the failed test should be addressed as soon as possible.
 |
| </li>
 |
| <li>
 |
| This process repeats as the team develops and continuously integrates and tests functionality in small increments.
 |
| </li>
 |
| </ol>
 |
| <h3>
 |
| Constraints
 |
| </h3>
 |
| <p>
 |
| Conceptually, continuous integration can be performed manually (see <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#SHO06" guid="_9ToeIB83Edqsvps02rpOOg">[SHO06]</a>
 |
| for example). However, in practice, there are several constraints that must be respected for it to be effective:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| All changes must be introduced into a tested configuration that you know to be good.
 |
| </li>
 |
| <li>
 |
| The integrate-build-test cycle must be fast enough so that it can be completed quickly and the team notified of the
 |
| results. Many published guidelines promote a 10-minute cycle.
 |
| </li>
 |
| <li>
 |
| Keep the <a class="elementLink" href="./../../../openup/guidances/concepts/change_set_430BF233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s&nbsp;small enough so that the work can be completed and integration
 |
| performed several times per day. Many published guidelines promote a 2- to 4-hour cycle between integrations.
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| These constraints imply the need for a configuration management (CM) repository to maintain configuration information
 |
| (Item 1 listed previously), automated build and test tools to meet the turnaround constraints (Item 2), and proper
 |
| planning and discipline by developers to ensure that their work items and change sets are small enough to complete
 |
| quickly (Item 3).
 |
| </p>
 |
| <p>
 |
| For a more detailed description of continuous integration, see <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#FOW06" guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a>
 |
| or <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#WIKP-CI" guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
