Source control, whats the best set up ..totally confused
My company was looking for source control tools when it discovered RTC. It looked perfect SCM with extra project type links so we could track code changes to project requirements however ......
I cant see how to set up RTC as an SCM tool, it all seems geared to project management So hear goes I have an application, by this I mean a collection of programs that perfrom actions to fullfil a business need, in my terms microsoft word is an application. the code in that application chagnes over time as a result of buisness requirements, the mechansim to deliver changes is a project - a project has a time time and an end point. My aplication must go through a change cycle of dev-> system test -> UAT -> where each of these is an executing enviornment My basic need is to be able to control changes into these executing environments. I want to know which versions of source relate to hte executables in each environment, and i may have versions at each level as I may be making changes for several projects. Just to give you the whole picture I have serveral applications. A project may require changes to be made to more than oen application. In RTC I appear to only be able to see source as part of a project, to me this is odd as the applicaiton lvies for ever and a project has a distinct end point ie when the code goes live. How do I do this in RTC, do I have a project per application ? A project per executing environment ? A project per 'real' project seems to leave you completely lost from an scm point ofview when you simply for example want to view your proudciton source code for example. 2 years down the lien dont acutally care which project delviered the change you jsut want to see which is hte current lvie version. help I am so confused I'm about to recommend we walk away from RTC. It cant be this hard to do something so simple |
5 answers
The same situation with me, It's a big challenge for RTC to manage complicated product development. Probably we need a "program" concept in RTC however it seems no way to realize in jazz now.
|
Hi Juile, I think you have hit on an interesting challange for RTC. projects 'own' in a sense all their artifacts which include their source code components and streams. I have talked with some organizations like yours where projects denote the activities around changing the source code in mulitple applications.
I haven't seen a perfect fit, but there are several options you can consider. One would use RTC projects for each application and your 'projects' (note the overloaded term project here). Each application RTC project would manage the source code(streams, components, builds) and Aviva projects would also be RTC projects to support the project management aspects - plans, work items. Users need to belong to all project they participate in, which is sort of cool because they can have different roles, permissions, etc. for each RTC project (application and Avivia project). I don't know if there is a way to share a component across projects - that would be ideal. I looked before but it doesn't seem like there is. |
julieataviva wrote:
In RTC I appear to only be able to see source as part of a project, to RTC uses a different definition of "project." A project in RTC lives forever. A time line has a distinct end point (often when a version of a product or an application is released to customers). But an RTC project can contain multiple time lines. How do I do this in RTC, do I have a project per application ? Here is my wild guess, based on very little information: An application would always be contained within a single RTC project. Each release of the application, which I think you refer to as a project, would be a time line within the RTC project. The executing environments might be iterations within the RTC time line (but I don't understand them well enough to be sure). If two of your applications are tightly coupled (if they are managed together, or if they are usually released together, or if they share a lot of code), then they should be part of the same RTC project. If two applications are unrelated, then they should be in separate RTC projects. If the applications are somewhat related, then one possibility would be separate RTC projects on the same server. (Different RTC projects on the same server can still share code and other resources and can refer to each other's work items.) |
|
harryk wrote:
I don't know if there is a way to share a component across projects - If the two RTC projects are running on the same server, then sharing SCM components between the projects is trivial. (The Jazz Foundation and Jazz RTC projects at jazz.net currently do that.) If the two RTC projects are running on different servers, then sharing anything between them is impossible. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 31 '09, 12:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, it is simple (and common) to do use RTC to do what you are
describing. I think you are just running into a terminology problem, primarily around the term "project". Detailed comments below. julieataviva wrote: My company was looking for source control tools when it discovered In RTC, as another responder has indicated, this is called a "timeline", not a "project". To avoid confusion, I often recommend people think of an RTC "project area" as a "process area". My aplication must go through a change cycle of dev-> system test If these executing environments are sequential (i.e. one never overlaps the other), then in RTC you would represent them as "iterations" in the timeline. If those environments run in parallel (as appears to be the case for you), then you would associate a "stream" with each environment. So you would have a "dev stream", a "system test stream", and a "UAT stream". My basic need is to be able to control changes into these executing Each application would then have its own set of streams (one for each executing environment of that application). In RTC I appear to only be able to see source as part of a project, to In RTC, you would have one project area for a given "overall process" (i.e. work item types and states, change request categories, etc.). Within that project area, you would have streams for your applications, as described above. A project per executing environment ? No, a stream per executing environment. A project per 'real' project seems to leave you completely lost from Yes, that is what you can do with a stream. You can see its "current version" of all files (but you can also ask for its history of how it got there, if you want).
Cheers, Geoff |
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.