How are builds and work items linked?
Is there a document that describes how the traceability between work items (and/or change sets) and builds?
We just started doing some RTC builds, and I am not really seeing what I would expect (for example, a failed build shows a contributing work item, but the next successful one did not). And the work items shows no build links. I am sure we might have "messed things up" as we were working to get our builds running successfully. I am mainly looking for something that explains the process for how builds and work items automatically get linked in RTC... Thanks in advance! |
6 answers
A build simply looks at the workspace being built on and inspects if there are any new change sets. If there are new change sets, it looks to see if there are work items associated with those change sets. If so, it links those work items to the build and lists them on the build record. It does not matter if those work items are completed or not -- as long as they reference source code which was accepted into the workspace during that build it creates a link from the work item to the build.
Why don't we see those work items the next time we do a build? They were already accepted into the build workspace so there are no new changes. However, if new change sets are delivered to the stream that reference those work items, the work item will be listed again. A common follow up question is then "How can I see all the work items included in a particular release -- not just the last build?" This comes down to build release strategy. You will likely want to create a special identical build that uses it's own "release build workspace." Once you have confirmed you are ready to do a release build, you would then kick off the release build. This build is going to accept all the change sets delivered since the last build. When you look at the release build record, you will now see all the relevant change sets listed. What if you accidentally do a build too early and forgot to verify that it would actually work? Is there any way of "going back" to pick up those work items again? Yes -- you can manually open up the release build workspace and discard those change sets or revert to a snapshot/baselines. The next time you kick off the build on that workspace it will discover those "new" change sets to accept in and list them on the build record. |
|
Thanks that helps a lot.
What happens when a build fails? Do the change set accepted into the stream get discarded to that it is re-accepted on the next build attempt until a successful build is achieved? Or is that what you mean by accidentally doing a build too early and needing to manually discard the change sets? |
|
That's what I meant by building too early and having to manually discard change sets.
Truthfully, you can't build "too early." Build early, build often. However, create a separate build workspace for your sprint/release builds strictly for tracking these release level changes. At least, that's the strategy I recommend. |
|
Got it. Good idea! Wouldn't have thought of that without understaind how it works.
Thanks! That's what I meant by building too early and having to manually discard change sets. |
|
No problem! Happy to help :)
And I'll also put a plug for Build Forge... when you're looking for more power in your builds (examples: parallel steps, WAS deployments, multiple machines, almost any platform) definitely take a look at Rational Build Forge -- it integrates beautifully into Team Concert. It's not necessary for some (small team, simple build process), but for many it has a very quick return on investment. |
|
I am trying to help a team ease into RTC. So baby steps my friend, baby steps!
|
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.