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.
- Needs wireless access to the team repository
- Consider a re-mastered Ubuntu Live-CD, or Ubuntu installed on a
pen-drive.
- Needs to be able to run both unit and integration scripts
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.