There is no formal training of this @ GE that I know of. I know of this stuff only through years of pounding it into my head by other UCM guys (and I constantly need both refreshment and research). It’s taken me a while to get some of these UCM concepts into my head – I know, from experience you need to repeat such definitions, concepts and procedures again and again. That’s how I learned. So I’m glad to reiterate them to you… You’ll also need to read this message over and over again stopping and reflecting about what was just said. Be mindful that composite != component, etc.
It’s best to think of this as a Producer/Consumer relationship. You may, at times, where either hat. Your production is a composite baseline that organizes a unique set of component baselines representing some functional milestone (e.g. The 2.1 release of Foundation). These are consumed by your “customers” who rely on the functionality set that the composite baseline represents. As such you should be mindful about how your “product” (Foundation) develops over time so that you can best serve your consumers/customers.
You’ve already performed an update of the Foundation jar set. The process or mechanics of it doesn’t really change that much. You join the Foundation project, perform your modifications, test, deliver to integration, perhaps retest the integrated changes and then produce a composite baseline (the process of doing so will force UCM to create new component baselines for all components that have changed in order to capture the change as a whole). This composite baseline is then “advertised” to your consumers as a baseline they may wish to use. It can also be recommended (i.e. set to be the default for the rebase operation). Consumers set the baseline in their projects by using the rebase operation. Since they consume your component as non-modifiable they are free to rebase both forward and backward in the timeline of your composite’s development (If they are modifying it as well as you then things get messy – hence the recommendation and current configuration that they consume these components as non-modifiable).
Since Foundation is a UCM Project/Stream like everybody else’s it has an integration stream associated with it. When you perform your work you work on a development stream and deliver to the integration stream. You don’t need to necessarily deliver to integration – you could produce a composite baseline on your development stream and advertise it to your consumers. Such a baseline should be thought of as more “experimental” and “to be integrated later”. After all this is why you have an integration stream – to integrate changes. Consumers could then rebase their streams to your more experimental baseline and try it out. If it fails they can easily go back to the recommended set. If they like it then you may consider the changes represented by this experimental composite baseline as “good to integrate into the main integration stream”/”tested in the field”.
If such divergences are longer lived you may wish to create alternate streams to support such a development line. I’m not sure you’ll need this. If so we can talk about that when the time comes.
Finally consumers can override any of the component baselines in your composite set during rebase. Doing so gives you warnings and notates the component baseline as “overridden”. Normally you should only do this for good reason and only to resolve what’s called a baseline conflict. This is an advanced topic and I don’t see it ever happening to your product (producer nor consumer) given the current configuration of the composite sets.
Consumers of your composite baseline therefore get your changes via rebase operations. But remember the consumer is also set up as an integration/development stream project (i.e. multistream). So again the consumers integration stream is usually where you would integrate the change to its composite baseline set including your new composite baseline. That would be done via a rebase on the consumer’s integration stream. Then they test and say “Yup that new composite baseline from the Foundation guys works well” and they can create a new composite baseline of their project including your composite baseline. Developers, working isolated on their work and probably with the last set of recommended baselines for their product (i.e. CE_CSY_Lyra) then can again use rebase to pick up the new recommended composite set from their project (CE_CSY_Lrya) that will include your latest recommended composite baseline. The rebase operation “merges” any changes into their development stream. But with respect to your composite, since they consume it in a non-modifiable fashion, there cannot be any merge conflicts or even merging going on. So the rebase of your portion of the composite merely incorporates your new functionality. (Other changes in modifiable components of the composite may be merged and require attention).
Like I said you’ll probably want to read this message a few times…
]]>
