Integration Lab


This document is preliminary and could be revised during the course. Importantly it doesn't yet describe the role of the integration monitor.

This document described how unit tested modules will be integrated.  Importantly, no source code is committed to the repository until the integration date determined in the integration plan.

Modules with no dependencies should be committed to the repository prior to this lab.

All unit tests scaffolding is committed to the repository after it is reviewed.  So the scaffolding should already be in the repository before this lab.

Each person brings their compiled and unit tested souce code on a USB drive.

Bring a laptop from which to do the integration.
Follow the module integration order in the Integration Plan.
Checkout the repository into a working directory on the laptop.
Developer of module 1 in the integration order copies their code from their USB drive to the working directory.
Compile the new code with the existing code.
Follow the defect repair procedure to track and fix any compile (integration) defects.
Run the unit tests.
Follow the defect repair procedure to track and fix any unit test defects (there shouldn't be any).
Run the "smoke" tests on the integrated system.
If time allows, run the integration tests.
Follow the defect repair procedure to track and fix any smoke or integration test defects.

Repeat for developer of module 2,3, .. n.

This exercise could possibly be run geographically distributed if there's a way to view the integration machine screen from the lecture room,
e.g., VNC.  So one student could go to CSL lab, and do the integration on a lab machine while providing the lecture room with a VNC view of their desktop and allowing others to monitor via text or voice chat.