It's all about the answers!

Ask a question

suggestion for leveraging RTC adopting scm apart from workitem management


anoop mc (74811200221) | asked Oct 11 '17, 11:18 a.m.
edited Oct 11 '17, 11:19 a.m.

 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



permanent link
Paul George (514) | answered Oct 11 '17, 11:52 a.m.

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.
If you are doing source control using some other tool, I'd politely suggest you are wasting your money on RTC. JIRA would be a much more cost effective solution for work item tracking. If you are using other CLM packages that might be different.


Comments
anoop mc commented Oct 11 '17, 1:16 p.m. | edited Oct 11 '17, 3:27 p.m.

 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.


Paul George commented Oct 11 '17, 1:35 p.m. | edited Oct 11 '17, 3:27 p.m.

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).


Paul George commented Oct 11 '17, 5:14 p.m.

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

See: https://www.ibm.com/support/knowledgecenter/SSCP65_6.0.4/com.ibm.team.scm.doc/topics/t_component_hierarchy.html


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.


permanent link
Matt Muller (59813674) | answered Oct 16 '17, 12:14 p.m.
edited Oct 16 '17, 12:15 p.m.

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


Register or to post 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.