| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-DlaqJu4sEqMPk84qhJ6IEA" |
| name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA" |
| changeDate="2007-07-13T14:47:43.207-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.html"
 |
| guid="_B3xkEPD0EdqYgerqi84oCA">Concept: Continuous Integration</a> and in <a class="elementLinkWithUserText"
 |
| href="./../../../openup/guidances/supportingmaterials/references.html#WIKP-CI"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
 |
| </p>
 |
| <h1>
 |
| Basic steps
 |
| </h1>
 |
| <p>
 |
| The detailed application of continuous integration depends on which tools you use (content 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 an to work on.
 |
| </li>
 |
| <li>
 |
| Jane updates her <a class="elementLink" href="./../../../openup/guidances/concepts/workspace.html"
 |
| guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> to include the most recent <a class="elementLink"
 |
| href="./../../../openup/workproducts/implementation-3.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.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline:
 |
| Promoting Changes</a>) to&nbsp;the&nbsp;integration workspace.
 |
| </li>
 |
| <li>
 |
| A complete <a class="elementLink" href="./../../../openup/workproducts/build.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>
 |
| <h1>
 |
| Constraints
 |
| </h1>
 |
| <p>
 |
| Conceptually, continuous integration can be performed manually (see <a class="elementLinkWithUserText"
 |
| href="./../../../openup/guidances/supportingmaterials/references.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.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 content 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.html#FOW06" guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a>
 |
| or <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references.html#WIKP-CI"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
