Stream/Component Structure for new RTC project
I'm setting up a new RTC project for an application that is structured as follows:
-Existing stand alone desktop app in pure maintenance mode by Team A -New web project designed to replace the stand alone app beginning construction by Team B. The new web project will use some of the code of the stand alone app until it can be fully rewritten (way down the road). Because of this, the web project may (but not always) have a dependency on the changes made to the stand alone app (depending on what's changed). The currect folder structure is setup as follows: -AppRoot ----StandAloneSrc1 ----StandAloneSrc2 ----StandAloneSrc3 ----StandAloneSrc4 ----WebProject --------WebProjectSrc1 --------WebProjectSrc2 --------WebProjectSrc3 There are also separate folders that hold infrastructure scripts and design documents that we want to keep in source control. Given this scenario, my initial thought was to have a)one stream with four components (StandAloneSrc,WebProject,Scripts,DesignDocs). - Changed folder structure to split out Stand alone and web code bases OR b)one stream with three components (StandAloneSrc and WebProject, Scripts, DesignDocs) - combined two code bases because of current folder structure and potential dependancy I also wrestled with the idea of a second stream, but couldn't think of a way to make that fit together. Any suggestions or best practices that could be recommended would be much appreciated. Regards, Doug |
5 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 15 '11, 1:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Or you could just put it all in one AppRoot component and leave the
directory structure the way it currently is. Some of the reasons for putting things in different components: - You want different access control for different folders (read and write permissions are most easily done on component boundaries) - You want to "mix and match" baselines of those different folders. Streams are largely about allowing for parallel development, so is largely independent of your component layout. Cheers, Geoff On 12/14/2011 6:08 PM, dverhun wrote: I'm setting up a new RTC project for an application that is structured |
|
|
Or you could just put it all in one AppRoot component and leave the Isn't this two projects and a producer/consumer pattern? Can we use something like this (I use to setup like this in ClearCase UCM): 1. Stream A has StandAloneSrc,ScriptsA,DesignDocsA, all stream and components are owned by Team A. ScriptsA,DesignDocsA stores only this desktop app related. Consider this is project A. 2. Stream B has StandAloneSrc,WebProject,ScriptsB,DesignDocsB, owned by Team B. ScriptsB,DesignDocsB stores only this web app related. Consider this is project B. StandAloneSrc is owned by team A, read-only in stream B (how . This way these two projects are separated. At a point, stream B just need to remove StandAloneSrc to be independent to project B. |
|
Thanx for your input Jirong! This was what I was struggling to elude to at the end of my first post with the two streams...I just didn't have it totally nailed down; but you've detailed it pretty much how I was thinking. From what I understand, both setups would work, and it would just depend on how we want the RTC project setup and how interdependent the groups are.
Given that it is two different teams working on the projects, I see the value of having two streams based on the baseline 'mixing and matching' Geoff referred to in his post. As I'm new to my company (let alone RTC), I'm still determining the dependency between the two teams (code and documentation dependency, release dependency - do they have to be released together?), which I think will help me determine which pattern to use once I learn more about them. This brought up another question I had though about streams and baselines. Given the simple scenario of one stream having one component with all the code; after a major release to production, is it better to create a new stream for that release; or just to create a new baseline for the component containing all the code/changed files? What would be the reason for using one approach over the other? Thanx in advance! |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 15 '11, 9:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The general rule of "create a new stream if you need to do parallel
development" applies to both of these cases. In particular, if the maintenance team and the new development team want to share the same configuration of their shared code, then they can both use the same stream. On the other hand, if the two teams want to be able to diverge (perhaps temporarily), then they would want their own streams. Similarly, if after the release, all development will be done for the next release, then you can just keep using the original development stream for the new release. On the other hand, if you will be producing patches to the original stream, in parallel with doing new development, then you will need two streams. In that case, it is up to you whether you use the original stream for patches to the original release and create a new stream for the new release, or use the original stream for the new release and create a new stream for the patches (they are functionally identical, from RTC's perspective). Cheers, Geoff On 12/15/2011 2:08 PM, dverhun wrote: Thanx for your input Jirong! This was what I was struggling to elude |
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.