It's all about the answers!

Ask a question

Streams and Components in Source Control Compared to Config Enabled PAs

Glyn Costello (13224) | asked Oct 19 '20, 9:12 a.m.


In Configuration Enabled PAs, there is a structure:
> Component
>> Stream 

In Source Control, it looks like the other way round, i.e.:

>> 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

permanent link
Nick Crossley (1463) | answered Oct 19 '20, 10:41 a.m.

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.

In OSLC, we call this abstract 'thing' a component. Components represent the logical or structural building blocks of a system or solution. A configuration describes the state of a component at some time, or for some purpose, and components are related to one another through configuration hierarchies. Components are containers for artifacts; configurations determine the versions of those artifacts to represent the state of the component.

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.

permanent link
Geoffrey Clemm (30.1k33035) | answered Oct 19 '20, 1:44 p.m.

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.

Glyn Costello commented Oct 20 '20, 11:51 a.m.

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?

Geoffrey Clemm commented Oct 20 '20, 1:59 p.m.

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.


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.

Glyn Costello commented Oct 26 '20, 3:12 p.m.

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.
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.

permanent link
Matt Muller (59813072) | answered Oct 26 '20, 1:06 p.m.
edited Oct 26 '20, 1:28 p.m.


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.


Matt Muller
SyntheSys Technologies

Glyn Costello commented Oct 26 '20, 3:15 p.m.

Are you suggesting separate PAs for each GC subsystem? 

Geoffrey Clemm commented Oct 26 '20, 7:49 p.m.

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

Register or to post your answer.