Question

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)?

Answer 1

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’:
.

This appears now as a configurable build definition parameter:

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.