| <?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" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.2.0" xmi:id="-DlaqJu4sEqMPk84qhJ6IEA" |
| name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA" |
| changeDate="2006-05-31T06:26:30.000-0400" 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 <a |
| class="elementLinkWithType" href="./../../../core.tech.slot.base/guidances/concepts/continuous_integration_87682D06.html" |
| guid="_B3xkEPD0EdqYgerqi84oCA">Concept: Continuous Integration</a> and in <a class="elementLinkWithUserText" |
| href="./../../../core.tech.common.base/guidances/supportingmaterials/references_6CCF393.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 (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="./../../../opn.swd.prac.legacy_pm/guidances/concepts/workspace_722BBA90.html" |
| guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> to include the most recent <a class="elementLink" |
| href="./../../../opn.swd.prac.legacy_impl/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="./../../../core.tech.slot.base/guidances/guidelines/promoting_changes_9087B764.html" |
| guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: Promoting Builds</a>) to&nbsp;the&nbsp;integration workspace. |
| </li> |
| <li> |
| A complete <a class="elementLink" |
| href="./../../../opn.swd.prac.legacy_impl/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> |
| <h1> |
| Constraints |
| </h1> |
| <p> |
| Conceptually, continuous integration can be performed manually (see <a class="elementLinkWithUserText" |
| href="./../../../core.tech.common.base/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="./../../../opn.swd.prac.legacy_pm/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_6CCF393.html#FOW06" |
| guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a> or <a class="elementLinkWithUserText" |
| href="./../../../core.tech.common.base/guidances/supportingmaterials/references_6CCF393.html#WIKP-CI" |
| guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |