|
CR Sharing Part I - Overview |
|
StarTeam has CRs integrated nicely into its object model, which is a big advantage. Many folks who set out to realize the promise implied by StarTeam's object model get hung up. In this series of posts, we will discuss CR Sharing in depth, along with the various places at which one could get hung up.
Short Version:
- Create a "All CRs" project, organize into folders
- Share particular folders into code views for "Process Item" links
- Do all reporting from the "All CRs" project
This sounds clear enough, no? If you've done it then you know that you can get hung up by...
- mysteriously duplicated files and/or CRs
- mysteriously branched CRs
- mysteriously unbranched files
- user confuzzlement
- which-build-was-that-really-addressed-in
...and other pitfalls. In this overview post, we will set the stage by describing the project/view/folder hierarchies in a hypothetcial example project. In subsequent posts, we will deal with the various issues implied by this overview. Lets suppose that we are developing a virtual bicycle.
- StarTeam Project BikeCRsContains all the CRs
- StarTeam Project BikeCode Contains all the code, branched per each Bike release into activity views. "Activity View" has a specific meaning per Randy Guck's best practices paper. I insist that you must read it. Here: http://bdn.borland.com/article/borcon/files/3262/paper/3262.html
| Folders in BikeCRs |
Views in BikeCode |
Folders in branch BikeCode/5.0 |
Folders in branch BikeCode/6.0 |
RootFolder
---Active
------5.0
------6.0
---Closed
------1.0
------2.0
------3.0 |
RootView
---5.0
---6.0
---Closed1.0
---Closed2.0
---Closed3.0 |
RootFolder
---change-requests
------5.0
---src
---etc ...etc... |
RootFolder
---change-requests
------6.0
---src
---etc ...etc... |
The release-level CR folders (5.0 and 6.0) are shared, each into its applicable code branch, BikeCode/5.0 and BikeCode/6.0 respectively. Hopefully, you can see in the table above that they are color-coded. Our hypothetical QA team might typically login to the "BikeCRs" project. By doing so, they always can view all the CRs across the various releases by using a higher level folder and the "all descendants" feature. This makes it easy to run reports across multiple releases. Further, our QA team can assign CRs to future releases by moving them from one folder to another, eg.g. from 5.0 to 6.0. Our hypothetical Development team would probably login to an activity branch in the "BikeCode" project. Such CRs as have been moved into the "BikeCRs/Active/5.0" folder, for example, are available as process items for checking into the BikeCode/5.0 activity view. Here are the problems that we will discuss in future posts...
- CRs should float while files should not. The natural expectation of our users will be that revising a CR in any place we find it will manifest in all places we find it. Specifically, if a developer fixes a CR in the BikeCode/5.0 view, then that CR should appear as fixed in the BikeCRs project view also. This is easily accomplished with floating shares, but StarTeam makes it difficult to float one item type while not floating another.
- What happens when a CR gets moved? StarTeam does not cascade moves, and so any movement of any shared CR is fairly sure to produce some kind of unwanted result. Same question applies to deletions.
- ...others?...
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
