<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-35rZhRLEVuTVI4280ncN0A" name="continuous_integration,3.193414568279561E-305" guid="-35rZhRLEVuTVI4280ncN0A" changeDate="2006-11-08T16:55:42.002-0800" version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_xp__continuous_integration&quot; name=&quot;XE_xp__continuous_integration&quot;&gt;&lt;/a&gt;&lt;a
id=&quot;XE_continuous_integration__practice_of&quot; name=&quot;XE_continuous_integration__practice_of&quot;&gt;&lt;/a&gt;&lt;a
id=&quot;XE_engineering_practices__continuous_integration&quot; name=&quot;XE_engineering_practices__continuous_integration&quot;&gt;&lt;/a&gt; 
&lt;h3&gt;
    Description
&lt;/h3&gt;
&lt;p&gt;
    One of the goals of XP is to ensure that the customer can feel and touch actual progress that reflects the investment
    to date. As the team builds the software incrementally according to the customer's priority, the new functionality is
    continuously integrated and demonstrated to the customer.
&lt;/p&gt;
&lt;p&gt;
    Integration in XP can happen several times a day. As developers finish some work, they integrate what they have done.
    Typically, integration is done on an integration machine in order to serialize the process. Integration is supported by
    unit tests and acceptance tests. When a pair of programmers first sits at the integration machine, the current code
    base passes all tests. They start by integrating their changes into the code and checking for conflicts. Then, they run
    all tests. Should any test fail, the pair is responsible for fixing the code and making it pass. Since the tests were
    all passed before, the failures are in some way related to the modifications that have made to the code. Once all the
    tests have passed, the integration can be considered a success and another pair can now integrate its changes. The
    integrated build can then be handed over to the customer, who can see the new functionality on a running system.
&lt;/p&gt;
&lt;p&gt;
    This practice obviously requires the use of tools and an environment that supports fast integration/build/test cycles.
&lt;/p&gt;
&lt;h3&gt;
    Benefits
&lt;/h3&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;b&gt;Simplified and faster integrations&lt;/b&gt;: reduces important conflicts associated with big bang integration and
        insures that people are working with the latest version of the code.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;Improved feedback&lt;/b&gt;: shows constant and demonstrable progress (it takes a running system to pass the
        customer's acceptance tests).
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;System always shippable&lt;/b&gt;: the latest version of the system passing all tests is always available.
    &lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>