suggestion for leveraging RTC adopting scm apart from workitem management
Hi Team,
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.
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
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.
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.
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.
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