| <?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="-35rZhRLEVuTVI4280ncN0A" |
| name="continuous_integration,3.193414568279561E-305" guid="-35rZhRLEVuTVI4280ncN0A" |
| changeDate="2006-11-08T19:55:42.002-0500" version="1.0.0"> |
| <mainDescription><a id="XE_xp__continuous_integration" name="XE_xp__continuous_integration"></a><a id="XE_continuous_integration__practice_of" name="XE_continuous_integration__practice_of"></a><a id="XE_engineering_practices__continuous_integration" name="XE_engineering_practices__continuous_integration"></a> 
 |
| <h3>
 |
| Description
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| This practice obviously requires the use of tools and an environment that supports fast integration/build/test cycles.
 |
| </p>
 |
| <h3>
 |
| Benefits
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| <b>Simplified and faster integrations</b>: reduces important conflicts associated with big bang integration and
 |
| insures that people are working with the latest version of the code.
 |
| </li>
 |
| <li>
 |
| <b>Improved feedback</b>: shows constant and demonstrable progress (it takes a running system to pass the
 |
| customer's acceptance tests).
 |
| </li>
 |
| <li>
 |
| <b>System always shippable</b>: the latest version of the system passing all tests is always available.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
