What is the best stream strategy for a production environment where the admins do all delivers
Below are my requirements on creating stream strategy:
- Roll back to certian period in time
- Need to know what code is in the production and each testing environment and much match up with the physical environments
- Need security that developers can not update code any where except in the development area
- All streams need to be read only that are not development streams
- Code needs to be moved to the different streams based on a production lifecycle
- For example module 1, 2, and 3 are developed, baselined and pushed to the Test stream
- Two different scenarios
- During testing they found an issue with module 2 but 1 and three passed testing and require moving to UAT.
- During testing they found an issue of a module in changeset 2 but changeset 1 and 3 are ready to move to UAT.
- Developers do not want to perform delivers and rebases
- Can they all work on one stream directly in eclipse?
The strategy we used in CC was
Integration stream = (Top level stream) push stream only no work performed
Main development stream = push stream only no work performed
Development stream = child of Main development stream code is performed
Test stream = child of development stream (Read Only)
UAT stream = Child of Main Development Stream (Read Only)
Perf stream = Child of Integration stream (Read Only)
Production Stream = child of Integration stream (Read Only)
One answer
From your description, only 3 streams are required: Development, UAT, and Production.
The process is:
- developers deliver their changes to Development, which has a "continuous build" defined on it that includes automated tests.
- based on the results of the continuous build, a tester will promote either a set of baselines or a set of change sets from Development to UAT.
- when UAT passes all of its tests, UAT is promoted to Production
But I assume there are additional use cases not identified here, to explain what the other ClearCase streams are for (Perf, Integration, Main Development, and Test). If you aren't sure if you really need them, just leave them out initially, since with RTC you can add them when you need them.
WRT controlling who gets to update a stream, with RTC you can define different permissions for each stream, so you can define that to be whatever you want.
WRT the simplest usage model for the developers ... each developer must have their own repository workspace, since the repository workspace is what keeps track of what the developer has in their configuration that isn't yet ready to share with the team (you can think of the workspace as keeping track of what is the the developer's file area on disk). Or in ClearCase terms, you can think of the repository workspace as being the "view" for a developer. When a developer is ready to share their work with the rest of the team, they would invoke the "check-in and deliver" operation. Conversely, when a developer want to update his files on disk with changes that have been shared by other members of their team, the developer invokes the "accept" operation.
The process is:
- developers deliver their changes to Development, which has a "continuous build" defined on it that includes automated tests.
- based on the results of the continuous build, a tester will promote either a set of baselines or a set of change sets from Development to UAT.
- when UAT passes all of its tests, UAT is promoted to Production
But I assume there are additional use cases not identified here, to explain what the other ClearCase streams are for (Perf, Integration, Main Development, and Test). If you aren't sure if you really need them, just leave them out initially, since with RTC you can add them when you need them.
WRT controlling who gets to update a stream, with RTC you can define different permissions for each stream, so you can define that to be whatever you want.
WRT the simplest usage model for the developers ... each developer must have their own repository workspace, since the repository workspace is what keeps track of what the developer has in their configuration that isn't yet ready to share with the team (you can think of the workspace as keeping track of what is the the developer's file area on disk). Or in ClearCase terms, you can think of the repository workspace as being the "view" for a developer. When a developer is ready to share their work with the rest of the team, they would invoke the "check-in and deliver" operation. Conversely, when a developer want to update his files on disk with changes that have been shared by other members of their team, the developer invokes the "accept" operation.
Comments
