Streams and Components in Source Control Compared to Config Enabled PAs
Hi,
In Configuration Enabled PAs, there is a structure:
> Component
>> Stream
In Source Control, it looks like the other way round, i.e.:
>Stream
>> Component
Can someone please explain why the difference? Is the intention that these are similar and mapped to each other in some way?
|
3 answers
The presentations are a little different, but the underlying concepts are actually the same.
Any configuration is a configuration of something - that is, a configuration represents a particular state of a more abstract concept. Typically that more abstract concept involves a collection of related artifacts; in SCM, that might be the set of source code artifacts needed to build a library or application. A stream is a mutable configuration - a configuration where things can change. You might have more than one stream for your library or application - perhaps one for a release you have nearly finished, and another stream for the next release. Those two streams are conceptually related - they are two different configurations of the same library or application.
EWM SCM does not make the component of a stream visible, but it is implicit in the way you think about different streams, and whether or not those are streams of the same thing.
In OSLC, a configuration may have contributions from other configurations, building up a hierarchy of configurations. This is most obvious in ELM's Global Configuration Management application, but it is also true for EWM SCM streams. An SCM stream has contributions from the configurations of each of the components in that stream - those components are being used as sub-components to the (invisible) component of the stream itself. This becomes more evident when you think about baselines in SCM: a stream is based not just on its components, but on specific baselines of those components, and changes to those baselines that you have added to the stream. Conceptually, an EWM SCM stream has contributions of the sub-streams for each sub-component (though EWM does not expose sub-streams as such).
Similarly, an OSLC baseline is an immutable configuration of its component. This corresponds directly to an EWM SCM component baseline, and to snapshots of the SCM stream.
Global configurations are configurations of global components; global components do not contain versioned artifacts directly, but provide a way to gather (and deliver in the form of global baselines) a coherent set of versions of the collected artifacts from EWM SCM, DOORS Next, ETM, and other applications.
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 19 '20, 1:44 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER I agree with Nick's answer, but will provide an alternative answer from a slightly different perspective.
The config-enabled PA approach is the more "flexible" approach. For any particular stream you select the set of configurations (baselines and other streams) that contribute to that stream.
The EWM Source Control approach is the "simpler" approach. For a given EWM stream, when you add an EWM component to that given EWM stream, you are effectively creating a "virtual" stream of that EWM component, and adding that stream as a contribution to the given EWM stream. When you remove that component from that given EWM stream, you are effectively deleting that "virtual" stream.
Comments Thank you both, I'm still not quite getting my head around it... perhaps an example might help using the GCM and RM structure... assume that the sys and sub-sys are from the same RM PA and EWM/RTC PA
Global Config:
> System Config 1
(RM Stream 1 for System Component)
>> Sub-System A Config 1
(RM Stream 1 for Sub-system A Component)
>> Sub-System 2 Config 1
(RM Stream 1 for Sub-System B Component)
So if I want to maintain a stream/component arrangement in EWM/RTC, am I correct with the structure below?:
EWM System Stream 1
Component: System
EWM Sub-System A Stream 1
Component: Sub-System A
EWM Sub-System B Stream 1
Component: Sub-System B
Then each of those EWM...Streams would sit along side the RM streams in each of the global configurations?
Thanks
Geoffrey Clemm
commented Oct 20 '20, 1:59 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You have a couple of choices. You could create explicit EWM streams in each of your EWM sub-system components, and contribute those to the appropriate GC sub-system configurations (and each EWM sub-system stream then sit alongside the RM stream). But to effectively populate EWM workspaces, you would want to flow all of those sub-system streams with an EWM system level stream. If you don't want to pay the overhead of creating those explicit EWM sub-system streams and keeping them in synch with the EWM system stream, you could just contribute the EWM system stream to the appropriate GC system configuration, and give up on having EWM sub-system streams sitting alongside the RM sub-system streams in the GC hierarchy. This is simpler ,but you lose the ability to create a baseline of that GC sub-system stream and have it capture the appropriate baseline from both RM and EWM.
Geoffrey Clemm
commented Oct 20 '20, 2:00 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note: I did submit an enhancement a while ago asking for the ability to reference from a GC those "virtual streams" that are automatically created by EWM (I believe that would be the ideal answer), but that enhancement has not yet been put in plan for implementation.
Thanks. Within our sub-system teams we operate relatively independently and there may be many months between sub-system releases/milestones and equivalent system releases/milestones. I think keeping them separate is probably better for us to be able to maintain separate baselines and releases throughout the project.
Geoffrey Clemm
commented Oct 26 '20, 7:40 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note that you can use a hybrid of the two choices I described earlier ... in case you want your sub-system EWM streams to contain multiple EWM components, you can contribute those sub-system EWM streams to your GC stream, while leaving the composition of those sub-systems into a system to be done by your global stream.
Also note that it is easy to evolve from one of these approaches to another, so you can always change your mind about which approach you want to take.
|
Glyn,
If you are starting to think about GC look into the impacts to reporting;
In my experience you almost need to look at the Project Structures and architecture you have in a different way.
It's essentially the GC and the GC Structure which will then enable you to refine the project "GC" and then use reporting LQE/GC. The solution extends beyond the traditional Projects / Teams etc.
It took me a while to get it into my head > You are creating product lines / configurations from a collections "Components" to form your project = GC Structure.
Regards
Matt Muller
SyntheSys Technologies
Comments Are you suggesting separate PAs for each GC subsystem?
Geoffrey Clemm
commented Oct 26 '20, 7:49 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The main reason to create a separate GC PA is if you have different read access requirements for different global components. Some customers who have a huge number of global components or streams create multiple GC PAs, but with appropriate naming conventions, this is usually not necessary because of the tagging and name-wildcard filtering provided by the GC application. |
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.