Streams and Components in Source Control Compared to Config Enabled PAs
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.
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
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