suggestion for leveraging RTC adopting scm apart from workitem management
Hi Team,
In one of the project RTC has been used for only workitem management.
We are looking for some of the best suggestion / recommendation from here
Scenario:
Company xyz use RTC widely for their workitem management
They have got only a single project area, where each team create one change request which follow certain workflow and once work related to CR is complete they manually set the CR status back to complete.
Use-Case:
Referring to one of the project / application we got to see they are having more than 50+ modules ( Cheque,Core Banking,E-Banking,Debit Card, CRR .... etc)
Now we are planning to get those project and modules create inside RTC SCM for storing their deployable files (e-banking.jar). (source code is managed by a different tool)
What do you recommend here to proceed with ?
Having a new project area and defining above modules - (50+) as components ?
Do we have a concept of creating Parent component the having sub-component ?
We are thinking over this and want to make a decision.
|
2 answers
I personally wouldn't use RTC (or ClearCase for that matter) as a package repository. I'd use something like protected flat file directories, Sonatype NRM, or UrbanCode deploy which are better suited to the purpose. I'd define modules/components in terms of the set of files that get deployed to a given type of server for a given application. RTC doesn't have a hierarchical structure for components. Note that the main purpose for components are populating streams (implying chnge sets) and creating baselines, which it appears you aren't really doing.
Comments Thanks Paul - Since RTC is already in place and not being effectively being used we thought of using this way along with Urban Code Build and Urban Code Deploy.
Right now we see there is lot of manual intervention involved.
Note: The application development is happening in this case.
Since UCD has it's own repository and artifact versioning, storing the binaries in RTC doesn't buy you anything but more work. If you are using UCB and not the RTC build engine, storing artifacts in RTC makes even less sense. In one place we did develop a work item to track the CM approval and deployment process, but it didn't involve change sets and the like. Net, if you are not using RTC for code development you are really not getting much bang for your buck. I understand it is a sunk cost, but still.
Geoffrey Clemm
commented Oct 11 '17, 3:31 p.m.
| edited Oct 15 '17, 1:27 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Just as a side note, RTC has support for a hierarchical structure for components (or to be precise, for configurations of components). It does?? Can you provide more detail or a link? Not sure what you mean by 'configurations' in this context. Components can be parts of multiple streams resulting in different 'built' packages, but I'm not clear on what you mean. CC had an actual hierarchical structure for components, thought it had some quirks.
Geoffrey Clemm
commented Oct 15 '17, 1:26 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
In RTC a "configuration" is just "one or more components in the context of stream, workspace, snapshot, or baseline". But folks often abbreviate "hierarchical component configurations" and just say "hiearchical components", because this distinction only matters in some advanced scenarios.
|
anoop, That is a really interesting question. I've worked with Clients doing both and it really depends on your business process and the products, releases and strategy you have. If you have RTC developer Licences then you are good to go for SCM? If not then you will need to define the development team and look into Licences. I would start by considering your Teams, Timelines and categories to help understand what Product/s are to be released and how. In Addition if you are tracking Changes / Defects then you should ensure you have "Releases" entered into your Project configuration this will help reporting (Dashboards). MOST important - Consider your Streaming Strategy > to manage Development vs Released versions. You should also document this process as part of your "Configuration Management Plan". To explain to users how to use Tooling to support Process who does dev and who can release. (lots of help on Jazz.net about Streams etc) You should consider some of the Operational Behaviours to help you: Ensure Component Names are Unique, All Children Resolved, Required Work Item and Comments. These changes will help to ensure you follow good practice I hope this helps and gives you some questions to consider moving forward; I would work to extend your Process Template and configuration to support the Process ; run a few trials and then start your journey. If you need inspiration I always look at how IBM use their RTC Instance for planning and managing their releases. (however they do use a very complex process configuration - with lots of checklists etc) Regards Matt Muller |
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.