| <?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-DlaqJu4sEqMPk84qhJ6IEA" name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA" changeDate="2008-05-28T07:33:07.000-0700" version="7.2.0"> |
| <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&nbsp;<a
 |
| class="elementLink"
 |
| href="./../../../practice.tech.continuous_integration.base/guidances/practices/continous_integration_58673D65.html"
 |
| guid="_rJNiMB4rEd2bS8fFOQ7WWA">Continuous Integration</a> and in <a class="elementLinkWithUserText"
 |
| href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_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="./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html"
 |
| guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> to include the most recent <a class="elementLink"
 |
| href="./../../../core.tech.slot.base/workproducts/technical_implementation_slot_E92F6A39.html"
 |
| guid="_Vux8UEfUEdyiPI8btkmvmw">[Technical 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="./../../../practice.tech.continuous_integration.base/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="./../../../core.tech.common.extend_supp/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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_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="./../../../core.mgmt.common.extend_supp/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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW06"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a> or <a class="elementLinkWithUserText"
 |
| href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#WIKP-CI"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
