Setting up streams for multiple consumers of a component project
Hi,
We a project that will deliver a common component (I hope this overloaded term doesn't make things to confusing in the rest of this post) to multiple consuming products. Our component will reside in it's own RTC project, each consumer will have they're own RTC project.
This will be run somewhat like an open source project in which the consumers will be able to make contributions and will build the component as part of their own product builds. The component project will also have direct contributions from the component project team.
We are in the process of setting this up in RTC and have a number of competing goals:
1. Enable features being worked on by different contributing consumers to be developed in isolation so that if one product's schedule is changed and work (e.g. epic scale work) won't be completed then this should not impact other products.
2. Enable features being worked on by different contributing consumers to be shared. We're a common component - a feature for our component is by definition useful to at least one other consumer otherwise our component is the wrong place for it.
3. Minimise the likelihood of mistakes in propagation of change sets, work space set up, stream set up. That is - minimise the complexity of the flow.
1 => each consumer needs it's own stream for development - this is not controversial. The question is where should this stream reside? In the consumer's on project in which case consumers can set up workspaces for their own project just consuming our RTC component from their own stream - simple to set up. Or if the stream is in our project then they would need workspaces flowing to multiple streams - their own stream for the consumer specific RTC components, and the component stream for the component specific RTC components.
2 => Having the stream for the component RTC components in the component RTC project seems to enhance this cross consumer visibility.
3 => It seems like we could kind of achieve what we want with a stream in the component project, a stream in the consumer project and have a consumer workspace flow to the consumer stream for consumer specific RTC components, and flow to a consumer specific stream in the component project for the component's RTC component. This would give easy visibility between consumers of the things they're working on. However requiring this seems complicated and error prone.
I suspect the best compromise will be something like:
Have a main development stream for the common component.
Have one integration stream (or possibly more than one such stream as the situation demands) for the common component that flows to the main development stream and allows for sharing of contributors' work as well as a staging/merging stream for contributions prior to delivery to the main stream.
Have consumers just operate a single stream in their own projects with the common component's RTC components added to it.
This seems simple to set up and the set of streams we manage for the component project is minimal. It might not provide quite the level of visibility but we're only starting out and therefore probably makes sense as a starting point for us to learn what the best practice - this approach should be fairly easy to evolve as it's starting off simple.
Does this make sense? Have I explained the scenario clearly enough? Are other people sharing code in a similar manner? What kind of set up do you use? How does it work for you?
Cheers,
Tim
One answer
A stream for each feature makes sense. My team works in this way. We accept changes from a main development stream on a regular basis to avoid a big merge when the feature is ready to ship. Development in the main stream can continue as usual.
For the feature stream's owner, this is dependent on your needs for process customization and permissions. You can make the feature streams a part of the main project but that's if you're ok that anybody in the project can see and deliver to the feature stream.
I personally don't mind having multiple repository workspaces loaded. I have one for components that I depend on that I don't need updated constantly. I'll accept changes from there at appropriate times. My other repository workspace contains components that I am working on and other components that I depend on and need to be updated often. I still work in a separate feature stream to isolate the changes from main development. However, this does require accepting changes from the main stream. It's an important part of this setup to avoid complicated merging later.
For the feature stream's owner, this is dependent on your needs for process customization and permissions. You can make the feature streams a part of the main project but that's if you're ok that anybody in the project can see and deliver to the feature stream.
I personally don't mind having multiple repository workspaces loaded. I have one for components that I depend on that I don't need updated constantly. I'll accept changes from there at appropriate times. My other repository workspace contains components that I am working on and other components that I depend on and need to be updated often. I still work in a separate feature stream to isolate the changes from main development. However, this does require accepting changes from the main stream. It's an important part of this setup to avoid complicated merging later.