It's all about the answers!

Ask a question

What is the best stream strategy for a production environment where the admins do all delivers

jeanie Keen (132023) | asked Jun 10 '13, 4:45 p.m.

Below are my requirements on creating stream strategy:

  1. Roll back to certian period in time
  2. Need to know what code is in the production and each testing environment and much match up with the physical environments
  3. Need security that developers can not update code any where except in the development area
    1. All streams need to be read only that are not development streams
  4. Code needs to be moved to the different streams based on a production lifecycle
    1. For example module 1, 2, and 3 are developed, baselined and pushed to the Test stream
      1. Two different scenarios
        1. During testing they found an issue with module 2 but 1 and three passed testing and require moving to UAT.
        2. During testing they found an issue of a module in changeset 2 but changeset 1 and 3 are ready to move to UAT.
  5. Developers do not want to perform delivers and rebases
    1. 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

permanent link
Geoffrey Clemm (30.1k33035) | answered Jun 10 '13, 5:32 p.m.
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.

jeanie Keen commented Jun 10 '13, 8:52 p.m. | edited Jun 10 '13, 9:14 p.m.

Thanks, the thing is the developers hated cc because they did not want to do the delivers and rebases.  Source control is just a minor part of thier job and need to focus on writing the code.  I just spent over an hour with someone working with CC trying to figure out their deliver/rebase issues. So i came up with an approach so they could all work on the same development stream they had thier views directly on the stream.  The code push to the next environment which was test we managed the deliver and rebase of the development stream.  The deliver was based on the activities that were ready to go to test.  If they passed test then they would request the push to be moved to uat, we would rebase uat then they would request a push to perf.  We would deliver to the main int and rebase perf stream  Then they would request a push to prod.  we would rebase the prod stream.  The compliance audit was between the perf and prod streams.  If anywhere along this process fails it was recycled through dev and back up the same process above and could not go to production until everything was ready.Iam hoping with the suspend we can pull things after they are baselined/snapshoted to allow us to pick and choose what we push the code to the requested stream.  I would like to know if the developers can work directly on a stream?

Geoffrey Clemm commented Jun 11 '13, 12:28 a.m. | edited Jun 11 '13, 12:28 a.m.

There are several questions here ... let's focus initially on the "can developers work directly on a stream" question.   In fact ClearCase with dynamic views is one of the very few SCM systems that lets a developer work directly on a stream ... almost every other SCM system requires a file to be copied into a user "file area" before it can be modified, and then copied back to the repository in order for the change to be seen by other team members.  RTC-SCM tries to make these "copy out" and "copy back" operations as simple as it can ... for example, if you are using the web client to update a single file, you specify the file you want to modify (which loads it into your file system), and then when you say you are done, it posts the new version back into the stream.   Alternatively, if you are working with multiple files, then there is a "batch copy out" operation (like a "get" or "checkout" or "load" in other SCM systems), and "batch copy back" operation.   The batch copy out operation in the Eclipse client is "load" for the first batch copy out, and "accept" for every time after that.   The batch copy back operation in the Eclipse client is "checkin and deliver" (a single operation).   If you or your users believe there is a way to avoid a "batch copy out" and a "batch copy back" operation in some other SCM system (other than ClearCase :-), please let me know.
But note that there is a complication when parallel development has taken place (two developers modifying the same file at the same time).   In that case, the second developer doing the "batch copy back" will need to do a "merge" of the first developer's changes before being able to complete the "batch copy back".   The web client avoids that problem by locking the file for the first developer (the second developer is not allowed to download the file for editing until the first developer does a "copy back".

Geoffrey Clemm commented Jun 11 '13, 10:44 p.m.

Note: I moved the latest comment on this answer to its own question, in:

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.