<?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="-b9r9AqTZkhRIh8JdHv5pDQ" name="new_roadmap,_4qbzQPnTEdyLA5PXdgVJXw" guid="-b9r9AqTZkhRIh8JdHv5pDQ" changeDate="2008-08-18T11:36:57.000-0700" version="7.2.0">
  <mainDescription>&lt;h3>&#xD;
    Getting started&amp;nbsp;&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The ultimate goal of continuous integration (CI) is to integrate and test the system on every change to minimize the&#xD;
    time between injecting a defect and correcting it. If the team is new to continuous integration, though, it is best to&#xD;
    start small and then incrementally add subpractices, as identified in the subsection that follows. For example, start&#xD;
    with a simple daily integration build and incrementally add tests and automated inspections (code coverage, and so&#xD;
    forth) to the build process, over time. As the team begins to adopt the sub-practices increase the build frequency. The&#xD;
    following subpractices provide guidance in adopting CI.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Developer practices&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Make changes available frequently.&lt;/b> For CI to be effective, &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html&quot;&#xD;
        guid=&quot;_1QU9MAIoEdyLh7vsrHZ4YA&quot;>Change Set&lt;/a>s need to be small, complete, cohesive, and &lt;em>available&lt;/em> for&#xD;
        integration. Keep change sets small so that they can be completed and tested in a relatively short time span.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Don't break the build.&lt;/b> Test your changes by using a private build before making your changes available.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Fix broken builds immediately.&lt;/b> When a problem is identified, fix it as soon as possible, while it is still&#xD;
        fresh in your mind. If the problem cannot be quickly resolved, back out (do not complete) the changes.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Integration practices&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A build is more than a compile (compilation). A build consists of compilation, testing, inspection, and deployment.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Provide feedback&lt;/b> as quickly as possible.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Automate the build process&lt;/b> so that it is fast and repeatable and so that issues are identified and conveyed&#xD;
        to the appropriate person for resolution as quickly as possible.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Automation&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Commit your test scripts to the CM repository so they are controlled and available to the rest of the team.&#xD;
        Automated testing is highly recommended, both for developer tests and integration tests. Tests need to be&#xD;
        repeatable and fast.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Commit your build scripts to the CM repository so they are controlled and available to the rest of the team.&#xD;
        Automated builds are highly recommended, both for private builds and integration builds. Builds need to be&#xD;
        repeatable and fast.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Invest in a CI server.The goal of continuous integration is to integrate, build, and test the software in a clean&#xD;
        environment any time that there is a change to the implementation. Although a dedicated CI server is not essential,&#xD;
        it will greatly reduce the overhead required to integrate continuously and provide the required reporting.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Common pitfalls&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>A build process that doesn't identify problems.&lt;/b> A build is more that a simple compilation (or its dynamic&#xD;
        language variations). Sound testing and inspection practices, both developer testing and integration testing, must&#xD;
        be adopted also to ensure the right amount of coverage.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Integration builds that take too long to complete.&lt;/b> The build process must balance coverage with speed. You&#xD;
        don't have to run every system level acceptance test to meet the intent of CI. Staged builds will provide a useful&#xD;
        means to organize testing to get the balance coverage and speed.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Change sets that are too large.&lt;/b> Developers must develop the discipline and skills to organize their work&#xD;
        into small, cohesive change sets. This will simplify testing, debugging, and reporting. It will also ensure that&#xD;
        changes are made available frequently enough to meet the intention of continuous integration.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Failure to commit defects to the CM repository.&lt;/b> Ensure adequate testing by developers before making change&#xD;
        sets available.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
