4
votes

I'm trying to set up automatic notifications for our test team so that they're told when they're ready to test a user story.

The notifications are currently firing when the "Fixed In" build for the work item changes.

Our nightly build deploys to a staging server. I want this build to update the "Fixed In" build.

In addition, we have a gated checkin build. I do not want this to update the "Fixed In" build.

I tried changing the "Associate Changesets and Work Items" property in the build definition to "false", but the gated checkin is still being associated with (and updating the "Fixed in" build of) work items.

How can I prevent my gated checkin from being associated with work items?

Is there another smarter way to automatically notify the test team when a work item is ready for testing (as opposed to just having been checked in)?

1
Does it also do the association with work items when you trigger a regular build? (Not a gated-checkin build)e-mre
It also associates checkins when I trigger a nightly build, or a staging deployment build. I want it to only notify users when I trigger a staging deployment build.Iain Galloway

1 Answers

3
votes

We have a similar set up, with 'private' builds being fired when developers check in in the DEV branch, and 'integration' builds that are actually the ones that are relevant to the test team.

Both 'private' and 'integration' builds derive from the same build process template, but are different build definitions.

We have constructed in the build solution a custom activity "Types.cs" (basically a simple enum):

namespace BuildTasks.Activities
{
    public enum QATypes
    {
        Private,
        Integration,
        Release
    }

}

This is passed as possible values of an build argument we have added named 'BuildType':
enter image description here.

This appears now as a configurable build definition parameter:enter image description here

We obviously enter 'Private' or 'Integration' in each definition accordingly.

In the final steps of our process, we check on the value of this param & depending on it we send (or not) an email to a QA alias.

It might be possible to organize a similar implementation to meet your needs.