What is the best stream strategy for a production environment where the admins do all delivers
Below are my requirements on creating stream strategy:
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
Geoffrey Clemm (30.1k●3●30●35)
| answered Jun 10 '13, 5:32 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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. Comments 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.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
Geoffrey Clemm
commented Jun 11 '13, 10:44 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note: I moved the latest comment on this answer to its own question, in:
|
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.