Criteria for tracker being shared or branched

Hi ​@M a r k u S 

I like to save Shared trackers for items that live outside the normal version or variant control of a product under development and will not be impacted by whatever version or variant of that product is being developed. This could be things like values driven by an ISO standard or a regulatory body. Another good question is to ask, if this value was updated or changed, would it impact all versions or variants, or only specific ones. As for how to use them, I recommend having them be downstream, so the reference field is place on the tracker that is consuming them so suspect flags are visible if the shared tracker changes. For trackers like releases and change requests, that is going to be more process driven and case by case, but a good indicator is if you want to be able to go into the shared tracker and see multiple versions or variants together, such as managing multiple versions / variants of a product within a shared release cycle.

Does this help?

What do you mean with “Release and change requests are more case by case”?

What’s about TestRuns (test results) - branched or shared? Well, their values would not a affect every version or variant → branched?

I don’t disagree with anything Brian posted (well, except for one thing … Test Runs are hard-wire to be shared items),  but I would have phrased it somewhat differently, as follows:

First, note that my guidance is based on a Codebeamer release with streams (3.1 or later).  For earlier releases, the notion of shared and branched were much less significant, so some of the statements below would not apply.  But even if you are not yet on 3.1, I still recommend you follow this guidance because at some point you will adopt 3.1 or later, and it will be easier to do so if you follow this guidance.

For questions 1 and 2, please see this page in the User  Guide: https://support.ptc.com/help/codebeamer/r3.3/en/index.html#page/codebeamer/user_guide/ug_streams_main_concepts.html

In general, an item that describes the state of the system would be branched (allowing you to work on different configurations of the system at the same time).  Other items (such as an item that describes a change you either want to make, are currently making, or have already made to the system) would be shared.  

I noticed there is a bug on that page: “Platform” is listed as both “Branched by default” and “Shared”.  A Platform tracker is actually branched by default (not shared)

But with that said I would consider that a Codebeamer bug … Configuration Items and Platform items should not be branched by default, but for most cases, they should be shared (because otherwise you can get anomalies when you merge between streams).  I will submit a Codebeamer change-request to get that changed.  Until then, just remember to set Configuration Item and Platform trackers to be shared, rather than leaving them as the default which is branched.

WRT where to store references between shared and branched items (a good question), an advantage of storing it on the branched item is that you can decide on each version of that branched item, whether or not it has that reference. So for references which effectively modify the behavior of the branched item, such as between a requirement and a configuration item, you will probably want to store the reference on the branched item.  On the other hand, an advantage of storing the reference on the shared item is that you can modify the reference without needing write access to the branched item, and it is more common to limit write access to branched items because they define the content of the system. So unless the reference effectively modifies the content of the branched item, you should store the reference on the shared item.

The “double negation” in your first sentence (“I don’t disagree”) confuses me…

Thank you for your explanation and you reference to the documentation. 

As I noticed, links from a shared tracker to a branched tracker will not be “duplicated” when you create a new stream. Right now, I’m not sure if this is a good idea or not?

Examples:

• The Bug Tracker is shared and links to a branched requirements tracker, for example. In other words, you can see the relationship between them in one stream, but not in subsequent streams. Is this what I want to have or not - honestly, I’m not sure, but likely this behavior is meaningful
  Short: BugTracker → RequirementsTracker; links are not duplicated for a new stream - seems to be fine.
• For example, a Change Request item (part of a shared tracker) links to a branched requirements tracker. The behaviour is as described for the bug tracker. However, I don't find this meaningful here, because in a subsequent stream, you won't have the information that the requirement was subject to a change request.
  Short: ChangeRequestTracker → RequirementsTracker; links are not duplicated for a new stream - not good, because changes of a requirements items might be not comprehensible anymore.
  Consequence (?): link RequirementsTracker → ChangeRequestTracker instead?
• The TestRunTracker (shared) links to the TestSetTracker (branched). So, in a new stream you cannot see, that there were already some test runs in an older iteration/release/stream. But this would be helpful.
  Why is the link direction of the TestRunTracker this way? Is it possible to change the direction?

You are correct that as of 3.1, CB no longer duplicates/modifies any references when you create a new stream, add a project to a stream, or add a tracker to a stream.  This is both more efficient (those duplication/modification operations were not cheap) and produces more predictable behavior. 

WRT shared->branched references, shared items do not have a stream context (only branched items have a stream context).  So unless the reference from the shared item is tied to a particular stream, the system wouldn’t know which stream it should use when navigating that reference. Logically, one could change the way Codebeamer works by saying every operation takes place in a stream context, but that would be a very expensive change to the Codebeamer code base.  This would only be worthwhile if this was extremely valuable functionality, so you would need to make the case why this behavior would be so valuable.

WRT test runs, the most important use case is “which stream does this result apply to”, so linking the test runs to all of the streams that have a given test case would break that use case (the result of that test run does not apply to all of those streams).  Note that this does not support efficient use case across multiple streams, which is a desired use case as long as it can be made reliable (only reused in streams where it is valid to reuse) … we are working on a design to support that use case.

WRT “I do not disagree” … that is just my way of agreeing with the content but not the way in which it was expressed.  

WRT test runs:

1. The test result applies to a specific stream - I agree. But wouldn’t this argue that test run trackers are “branched trackers”?
2. Furhter: the detail view of a test set has a tab for the test runs, where you can filter for the Release.

   

   There is no sense anymore, when we have a stream for each release (which is one described use case in “Product Development using Streams in Codebeamer 3.2”, isn’t it?

What sense does it make to select a “Release” in the test case when following the Release Stream approach as recommended in the best practice?

​@Brian Kampling Do you know the PTC document “Product Development using Streams in Codebeamer 3.2”? I just wonder what it is if not a “best practice” as titled by PTC. 

I agree, that the configuration as “shared” or “branched” tracker highly depend on the situation. On the other side, I wonder why some things are “hardcoded” and not flexible (tracker Test Runs can not be configured as “branched”, Test Sets contains “hardcoded” a “Release” field - which doesn’t make sense any more when you are using Release Stream - to mention only some examples).

It’s published by PTC. Please ask PTC to get the best practice.

I found it. Looks like they moved it from 3.2 to the 3.3 docs.
https://support.ptc.com/help/codebeamer/r3.3/en/index.html#page/codebeamer/user_guide/ug_streams_best_practices.html