How to populate "Found In" field
Hello,
We are using RTC for the work items and agile planning only at this point. Is there a way to have the values in the "Found In" drop down automatically populated when we create "builds". Our build process is automated in Build Forge. I would rather not setup the integration at this point, but just add a step to the existing automated build process that would update RTC some how so the each build appeared in the "Found In" field. Any advice on the best way to do this? As a point of reference, we have one RTC "Project". Beneath that we Release teams, and beneath that we have feature teams. Most typically, each "Release team" has the builds, occasionally the "Feature Teams" have a build, rarely does the "Project" itself have a build. I felt this was important since we have many different builds going on, and ideally this "Found In" field only listed the builds that were applicable to the "Team" for which the defect is being reported against. |
4 answers
Ralph Schoon (63.6k●3●36●46)
| answered Jun 30 '10, 3:03 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi James,
to get the expected values in the "Found in" you would have to create a release from the build result (the link on the build result overview). I could not find a jazz build ant task to do that. I'd suggest to create a release for the Milestone/Release you are working towards. It is possible to create a link to the actual build in the work items links section. This is automated in some cases e.g. if creating a defect directly from the build result. However it would only work f you have the BuildForge integration running. An alternative could be to look into the API (Plain Java API) ant try to figure if there is a way to create a release using the API. If that is the case it could be done in the build script. I am not sure it would be a good idea, because maintaining the release list in the project might get hard if you have too many entries. You can find discussions about these kinds of topics (API) in the Extending Team Concert Forum. Just my thoughts, Ralph Hello, |
|
I'm sure we can figure something out with the Java API. But you bring up an interesting concern about a very large list.
Typically we have people working on releases in parallel. In RTC, we have a project, with a Main Line Development timeline, and child timelines for each Release. In the midst of development, each Release is creating a "build" that is then consumed and tested by our verification teams. We call these "internal releases". Often times each Release is creating it's own "build" on a daily basis. This means across the "Project" (in RTC terms) there are going to be several "builds" a day. My assumption is that the "Found In" field for a defect work item should correlate with one of the "build" that is produced by the Release and tested by a verification person. I know we are not a unique company with way we are organized in this regard. If my assumption about the purpose of the "Found In" field is correct, then wouldn't a large list be inevitable? If my assumption is incorrect, then what is the purpose of the "Found In" field and how do Defects get correlated to the appropriate "internal release". |
|
Ralph Schoon (63.6k●3●36●46)
| answered Jul 01 '10, 8:59 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Jim,
I can't comment on what others do. The filed against used in the work items on Jazz.Net seems to be used as I described. For each Milestone/Release there is one entry. 2.0M5 2.0.0.2IFix2 etc. The work items are filed against those. In RTC a work item is created against a build e.g. a special 2.0M5 Build#1234 is connected to that build using a special link (found in build on the Links tab). That link is actually automatically created, if you create a work item on the Build Result. This should work with Build Forge Builds if the integration is active. Maybe others have other suggestions. Ralph I'm sure we can figure something out with the Java API. But you bring up an interesting concern about a very large list. |
|
Ralph,
I see what you are saying. If anybody else, maybe even people on the RTC dev team, could comment on the "best practice" for correlating Defects with "builds" that are only released within the team that would be great I have a feeling that my assumption on creating a "release" entry for each one of these really isn't the way to go about this. As you mentioned, it will get messy fast. |
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.