| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\openup_basic\guidances\guidelines\continuous_integration.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: continuous_integration.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_i8bUEL6cEdqti4GwqTkbsQ CRC: 751312288 -->Continuous Integration<!-- END:presentationName,_i8bUEL6cEdqti4GwqTkbsQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_i8bUEL6cEdqti4GwqTkbsQ CRC: 1413011866 -->This guideline describes how to apply continuous integration to improve the integration of units into the code base.<!-- END:briefDescription,_i8bUEL6cEdqti4GwqTkbsQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-DlaqJu4sEqMPk84qhJ6IEA CRC: 1153667371 --><p> |
| [ Don't forget to talk about running developer tests. ] |
| </p> |
| <p> |
| [Content below taken from step “Accept Integrated Elements and Promote Build" in the Task “Integrate and Create |
| Build"... this Main Description needs to be cleaned up ] |
| </p> |
| <p> |
| Depending on the complexity and number of components to be integrated, it is often more efficient to produce the |
| target build in a number of steps, adding more components with each step, and producing a series of intermediate |
| 'mini' builds - thus, each build planned for an iteration may, in turn, have its own sequence of transient intermediate |
| builds. These are subjected to a minimal integration test to ensure that what is added is compatible with what |
| already exists in the system integration workspace. It should be easier to isolate and diagnose problems using this |
| approach. |
| </p> |
| <p> |
| Delivered components are accepted incrementally into the system integration workspace, having any merge |
| conflicts being resolved. It is recommended that this is done in a bottom-up approach with respect to the |
| layered structure, making sure that the versions of the components are consistent, taking imports into |
| consideration. The increment of components is compiled and linked into an intermediate build, which is then |
| provided to the tester to execute a minimal system integration test. |
| </p> |
| <p> |
| <font size="1"><img height="172" alt="" src="./resources/ac_intsy.gif" width="501" /></font> |
| </p> |
| <p> |
| This diagram shows a build produced in three increments. Some components are only needed as stubs, to make it |
| possible to compile and link the other components, and provide the essential minimal run-time behavior. |
| </p><!-- END:mainDescription,-DlaqJu4sEqMPk84qhJ6IEA --> |
| </body> |
| </html> |
