1. Using Siebel Tools
  2. Basic Workspace Structure

Basic Workspace Structure

The following image illustrates one example of the basic recommended structure for a Workspace.

Example of the basic recommended structure for Workspaces.

As shown in this image, the main elements in a typical Workspace structure are as follows:

  • There are releases being developed in parallel. For example: October and November releases.

  • Each release has its own features. For example: October has Feature A and B, November has Feature C and D.

  • Each release has bug fixes planned with Workspaces for each fix under the corresponding release IWS.

  • Each feature has developers working on it with each developer having their part in a unique Developer Workspace. For example:

    • Developer 1 and 2 work on Feature A and Feature C.

    • Developer 1 and 3 work on Feature B.

    • Developer 2, 3, and 4 work on Feature D.

  • As developers finish work on a bug or partial feature, QA – who are part of the development team – should help unit test changes in the Developer Workspace.

  • The Developer Workspace should be delivered to the parent branch for integration testing only when both developer and QA are satisfied that it is operating properly when tested independently of other features and/or bug fixes. For example: When Developer 1 finishes their work on Feature A and the QA team is satisfied, the developer will deliver to the parent Integration Workspace (Feature A).

  • After delivery to the parent Integration Workspace (IWS), the testing should focus on determining whether this set of developer changes integrates well with other developer changes. Since you have already unit tested it and confirmed the unit test by QA, all you are worried about in the IWS is whether the individual developer changes conflict with other developer changes or not.

  • When an entire feature is ready, the feature is delivered to the release level. For example:

    • Feature A and B are delivered to the October Release level.

    • Feature C and D are delivered to the November Release level.

    You can migrate the October release content to a UAT (User Acceptance Testing) environment and test it there while continuing to work on the October release and the November release in parallel.

  • Test the release (User Acceptance Testing and Integration Testing).

  • When the entire release is ready, deliver the Release to MAIN.

  • Immediately migrate MAIN to Production.

    MAIN must always match your Production release.