Activity: Create Integration Workspaces

Purpose Similar to the implementers’ ‘private workspace’, where individuals can develop and change code in a contained area, is the notion of integration workspace. The integration workspace is where subsystem and system integrators convince themselves that separately developed and tested components can indeed work together as a product.
Input Artifacts: Implementation Model Implementation Subsystems, tested Components, tested	Resulting Artifacts: Implementation Subsystems, integrated Integrated System (Product)
Frequency: On-going as part of the Iterative Development Process
Worker: System Integrator
Tool Mentor: Using ClearCase to Create an Integration and Build Workspace

Once an implementer has finished implementing a component in accordance with the project’s adopted Implementation Workflow, the tested and approved component is ‘promoted’ for integration. System Integrators, who are responsible for the integrity of the integration workspace, need to work with the ‘latest available version’ of any given component, and therefore must be aware of any dynamic changes to the source code. As such, promoted code should be immediately visible to them.

In creating an integration view ensure that that the latest (most mature) version of the developed and promoted software is available for integration. Given the maturation process of software undergoing development, the integration view needs to be a ‘dynamic’ view of the evolving software.

As team members promote changes over the course of the project, builds may be performed on a nightly, weekly, or at any chosen interval. Each build needs to be labeled to ensure that it is uniquely identifiable and re-creatable in case there is a need to revert to a prior build.

Integrators should label builds when they are ready for integration. An example label for a candidate build could be <PROJECT>_BUILD_CANDIDATE_#. The label should be changed when identifying a baseline or a known stable build as follows <PROJECT>_<RELEASE>.BL<#>.