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