如何防止 TFS 将工作项与构建关联?
我正在尝试为我们的测试团队设置自动通知,以便他们在准备好测试用户故事时得到通知。
当前,当工作项的“固定”构建发生更改时,会触发通知。
我们的夜间构建部署到临时服务器。我希望此版本更新“固定”版本。
此外,我们还有一个封闭的签入构建。我不希望它更新“固定”版本。
我尝试将构建定义中的“关联变更集和工作项”属性更改为“false”,但门控签入仍与工作项关联(并更新工作项的“固定”构建)。
如何防止我的门禁签到与工作项目关联?
当工作项目准备好进行测试时(而不是刚刚签入),是否有另一种更智能的方法来自动通知测试团队?
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)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我们有一个类似的设置,当开发人员在 DEV 分支中签入时,会触发“私有”构建,而“集成”构建实际上是与测试团队相关的构建。
“私有”和“集成”构建都源自相同的构建过程模板,但是是不同的构建定义。
我们在构建解决方案中构建了一个自定义活动“Types.cs”(基本上是一个简单的枚举):
它作为我们添加的名为“BuildType”的构建参数的可能值传递:
。
现在,这显示为可配置的构建定义参数:
我们显然在每个中输入“私有”或“集成”相应的定义。
在流程的最后步骤中,我们检查此参数的值和根据它,我们会向 QA 别名发送(或不发送)电子邮件。
也许可以组织类似的实施来满足您的需求。
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):
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.