Several RTC Process Questions
Hello all,
My team has been using RTC successfully for over a year. Our experience has prompted the larger organization to consider moving to RTC (from a collection of various tools) as well. However, that larger team has posed a series of questions. "Can RTC duplicate this behavior?" sort of questions. I'd like to pose them here. (I'll number them so that they can be individually addressed.) Please answer them if you are able. As I find answers on the site, I'll answer my own questions as well. Please correct me where I'm mistaken. 1. Can dependencies be set up between change sets? (In our prior tooling, one change set could be marked as a prerequisite or a co-requisite of another.) 2. Can I make it possible to require code review on individual change sets? (I know I can require them for work items. If I'm only allowed to require them for work items, can I restrict the cardinality in the change sets/work items relationship?) 3. Is it possible to restrict component creation? 4. Is it possible to restrict baseline creation? 5. Can RTC be set up to open defects automatically in response to build failures? 6. Is it possible to make some fields mandatory when creating defects? 7. We have some areas of code that at present require an approval process before we allow changes. (i.e. Should be treated differently than just requiring the general code review - we want to restrict who can provide the kind of approval outlined in this question more than we want to restrict the general list of who can code review.) |
One answer
The dependencies are implicit by the files they modify and the states that they build upon. We have work planned to help visualize what they are, but for now we calculate on accept/deliver and warn when dependencies are missing (eg, gaps). We also won't have cross component dependencies. For now you can use a work item to track related change sets, and accept, suspend them together.
No, but there exists integrations between RTC and tools such as SmartBear which provides the extra level of file level review/collaboration.
Yes and no. If someone has a developer license they can create personal components. Components created and owned by a project/team is controlled by the permissions configured in that project. So someone can't just create a component and assign it to a team.
Yes, at the project level there are permissions. Also, you need permission on the target (stream/workspace) in which they are being created.
Not without some scripting on your side, such as using the OSLC APIs to create defects. But we've heard of similar requests, such as opening and assigning to people based on the tests that have failed.
Yep.
You can require approvals based on the role of the approver. You can also control when change sets can be attached and remove from change sets, such that after a review and the work item is closed, the work item is frozen and the change sets can't be removed or added. You can't however currently control the cardinality. Cheers, Jean-Michel |
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.