It's all about the answers!

Ask a question

Can I link an existing release to a build result?

Bill Higgins (4562423) | asked Jul 19 '12, 11:26 p.m.
(Using RTC 3.0.1)

It is very easy to link a build result to a release if you create the release via the Build Result UI ("Create a release to associate with this build").

However, I have inherited management of a project area where someone apparently created some releases directly from the Project Area Editor (Releases -> Add...).

Is there any way I can link one of these existing releases with a build result? There doesn't seem to be a way, either from the Build Result UI nor the Project Area Editor. I wish it were as easy as the way you can both create a new work item from the Build Result UI or associate an existing work item.

Accepted answer

permanent link
Nick Edgar (6.5k711) | answered Jul 20 '12, 7:26 p.m.
 Bill, this is not currently possible.  There is an existing enhancement request for this here: 57136: Manage artifacts associated to a release.

Ralph Schoon selected this answer as the correct answer

Bill Higgins commented May 07 '13, 9:07 p.m.

Hi Nick, I see you referenced some Jazz Java API stuff below. Would it be possible for me to achieve my need above if I wrote some code myself using the Jazz Java API? 

Nick Edgar commented May 07 '13, 9:59 p.m.

Yes, see answer below with snippet.

4 other answers

permanent link
Nick Edgar (6.5k711) | answered May 07 '13, 9:59 p.m.
edited May 07 '13, 10:06 p.m.
Bill asked about API to set the build associated with an existing release.  Instead of creating a new release like in the UI code mentioned above, you'd modify an existing one -- set its artifact to be the build result handle, then save.
IDeliverable deliverable = ... // find/fetch the deliverable (aka release)
IBuildResultHandle buildResultHandle = ... // find the build
deliverable = (IDeliverable) deliverable.createWorkingCopy();
IWorkItemClient workItemClient = (IWorkItemClient) teamRepository.getClientLibrary(IWorkItemClient.class); 
workItemClient.saveDeliverable(deliverable, subMonitor.newChild(1));

permanent link
sam detweiler (12.4k6180201) | answered May 07 '13, 7:24 p.m.
sorry to bring back an old item, but I have a related question..

because of the way we do software, I want to replace 'release' artifacts with a workitem.
can I customize the 'create a release' link in the build record ui?

permanent link
Nick Edgar (6.5k711) | answered May 07 '13, 7:52 p.m.
Hi Sam, do you mean you want a release to be associated with a work item instead of a build, or that you want the build to be associated with a work item instead of a release?

A release is actually in the Work Items object model, and is called an IDeliverable.  It has an (optional) associated artifact, which in normal usage is a handle to the build result (IBuildResultHandle), but is typed to be any item handle (IItemHandle).

The UI code is in Build:
but is not currently designed to be extensible.

Nick Edgar commented May 07 '13, 7:53 p.m.

Note that we also have the "reported against build" work item link type, but there's no special semantics there indicating that the linked work item captures the release.

permanent link
sam detweiler (12.4k6180201) | answered May 07 '13, 10:35 p.m.

we have a lot of software products. they range from mobile platforms to mainframe.
of course we have new development and we have product maintenance development.
the product maintenance can be as small as a mainframe module patch to a full cumulative release of a product on a quarterly basis (sort of like rtc deliveries)

we have at least 5 different targets of 'delivery' of some artifact package.
an External SaaS runtime, our internal Operations platform, our QA platform, our product manufacturing platform (create media, etc) and our Customer Support platform.

log story short, I need an artifact in the system that I can attach attributes, workflow with states, approvals, links to physical entities (zip package in library for example, aka , build output), links to contributing sources (defects, stories, ...), (aka, a workitem).

and these 'workitems' are built as part of the process.

A change set causes build, which creates a thing that is distributed to test, which creates defects ('found in'),
cycle repeats.. that produces a similar artifact with additional materials (links to bill of materials), now its an
'official' releasable entity.which has to be delivered,

but then has customer support issues/defects against (found in), which causes a change set, which creates an artifact, that has OS, pre-reqs (released thning), co-reqs(released thing) and supercedes (released thing), and some of our product teams have multiple streams active at customers. so one 'defect' resolution might appear in multiple future 'released' things. (and we track 'planned to be delivered' vs 'actually delivered')

so some of these deliverables are for the future, and we 'collect' defect and other contributions, and fire off a release on a schedule.

and I need to automate the transport of the artifacts to their destinations.. fix artifacts go to the support delivery system, saas to that channel, internal IT to that channel, etc.

and with full traceability back to their origins (all the way back to the requirement in the product mgmt system maybe)

the IDeliverable is 'nice', but way too primitive

I want the 'system' to help do all this, in some consistent way.. you build a deliverable, it was tested and approved. and it should flow to its target. for those that have complex flows, it may be a bi directional workflow
customer gets test fix, confirms it, then we repackage with the final doc etc.. (all of which flows thru the support system which has different artifact objects, numbers, ...)

so, if I end up with a new workitem(to hold all this metadata), I need to be able to change the 'create a "release"' link to create one of these, and link back to the build record (which links it to the contributing change sets, workitems, testcases executed (and not))

'reported against build' link.. see that semantic has a problem.. why isn't it 'reported against'  and the target workitem is just a deliverable. (I built found in/fixed in links , but I think a 'workitemlist' type object is really the semantic (altho I want a different UI to reduce the presentation space consumption).. 1 to many (without the burden of link artifacts too).. but its got to be a concrete workitem on the other side.

if you did it all with a workitem, automated test could run a scheduled query , find all the new 'delivery' workitems created since last scan of type 'build' (or push a record on a queue) and decompose their linked sources and gen the test set that verifies that content. 

a 'product' deliverable would test a different set of stuff. something that transitions to 'approved' flows to its target channel. this is where the back part of DevOps picks up. Taking the deliverable and loading it into the runtime for that channel under the direction of the approved processes.

Your answer

Register or to post your answer.