TeamCity：管理验收测试的部署依赖项？
我正在尝试在 TeamCity 6 中配置一组构建配置，并尝试以 TeamCity 启用的最干净的方式对特定需求进行建模。
我有一组验收测试（大约 4-8 套测试，按它们所属的系统功能区域分组），我希望并行运行（我将它们建模为构建配置，以便它们可以分布在代理集）。
从我最初的研究来看，似乎有一个 AcceptanceTests 元构建配置，可以通过 快照依赖项 应该可以解决问题。然后我所要做的就是说我的 Commit 构建配置应该触发 AcceptanceTests 并且它们都会被拉进来。所以，假设我也有 AcceptanceSuiteA、AcceptanceSuiteB 和 AcceptanceSuiteC
到目前为止，一切顺利（我知道我也可以以其他方式扭转它并导致 Commit配置触发 AcceptanceSuiteA、AcceptanceSuiteB 和 AcceptanceSuiteC - 问题是我需要手动聚合结果以确定验收测试的总体成功情况一个整体）。
复杂的一点是，虽然 AcceptanceSuiteC 只需需要一些 Commit 工件，然后就可以独立存在，但 AcceptanceSuiteA 和 AcceptanceSuiteB > 需要：
DeploySite（假设这需要 2 分钟，而且我无法为此运行启动一个完全隔离的站点）- 针对已部署的站点运行测试
问题是我需要能够确保：
- 网站仅配置一次
- 在两个套件运行时网站不会被破坏
如果我将 DeploySite 设置为构建配置并具有 AcceptanceSuiteA 和 < code>AcceptanceSuiteB 将其作为快照依赖项拉入，AFAICT：
AcceptanceSuiteB的后续或并行运行可能会触发另一个DeploySite，这会破坏的部署>AcceptanceSuiteA和/或AcceptanceSuiteB正在使用中。
虽然我可以说限制同时运行的构建数量以强制一次只发生一个，但我需要一次有一个并且而不是当依赖项处于运行状态时仍在运行。
TeamCity 中有没有办法对这样的层次结构进行建模？
编辑：想法：-
一个糟糕的解决方案是 DeploySite 可以设置一个“使用中标志”标记，然后让 AcceptanceTests 配置清除该标志 [在 AcceptanceSuiteA< 之后/code> 和 AcceptanceSuiteB 已完成]。然后，问题就变成了让管道中的下一个 DeploySite 等待，直到再次打开所述门（在构建中进行阻塞等待，感觉不对 - 我希望将其标记为“不”）尚未开始”而不是看起来需要很长时间才能做某事）。然而，这种东西在这里有一个标志，并有一点检查它是我试图摆脱的那种可变状态/片状气味。
编辑2：如果我可以以编程方式更改代理配置，我可以设置 代理要求要求InUse=false，然后在部署开始时设置该标志，并在测试运行后清除它
I'm trying to configure a set of build configurations in TeamCity 6 and am trying to model a specific requirement in the cleanest possible manner way enabled by TeamCity.
I have a set of acceptance tests (around 4-8 suites of tests grouped by the functional area of the system they pertain to) that I wish to run in parallel (I'll model them as build configurations so they can be distributed across a set of agents).
From my initial research, it seems that having a AcceptanceTests meta-build config that pulls in the set of individual Acceptance test configs via Snapshot dependencies should do the trick. Then all I have to do is say that my Commit build config should trigger AcceptanceTests and they'll all get pulled in. So, lets say I also have AcceptanceSuiteA, AcceptanceSuiteB and AcceptanceSuiteC
So far, so good (I know I could also turn it around the other way and cause the Commit config to trigger AcceptanceSuiteA, AcceptanceSuiteB and AcceptanceSuiteC - problem there is I need to manually aggregate the results to determine the overall success of the acceptance tests as a whole).
The complicating bit is that while AcceptanceSuiteC just needs some Commit artifacts and can then live on it's own, AcceptanceSuiteA and AcceptanceSuiteB need to:
DeploySite(lets say it takes 2 minutes and I cant afford to spin up a completely isolated one just for this run)- Run tests against the deployed site
The problem is that I need to be able to ensure that:
- the website only gets configured once
- The website does not get clobbered while the two suites are running
If I set up DeploySite as a build config and have AcceptanceSuiteA and AcceptanceSuiteB pull it in as a snapshot dependency, AFAICT:
- a subsequent or parallel run of
AcceptanceSuiteBcould trigger anotherDeploySitewhich would clobber the deployment thatAcceptanceSuiteAand/orAcceptanceSuiteBare in the middle of using.
While I can say Limit the number of simultaneously running builds to force only one to happen at a time, I need to have one at a time and not while the dependent pieces are still running.
Is there a way in TeamCity to model such a hierarchy?
EDIT: Ideas:-
A crap solution is that DeploySite could set a 'in use flag' marker and then have the AcceptanceTests config clear that flag [after AcceptanceSuiteA and AcceptanceSuiteB have completed]. The problem then becomes one of having the next DeploySite down the pipeline wait until said gate has been opened again (Doing a blocking wait within the build, doesnt feel right - I want it to be flagged as 'not yet started' rather than looking like it's taking a long time to do something). However this sort of stuff a flag over here and have this bit check it is the sort of mutable state / flakiness smell I'm trying to get away from.
EDIT 2: if I could programmatically alter the agent configuration, I could set Agent Requirements to require InUse=false and then set the flag when a deploy starts and clear it after the tests have run
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来你去看看 Jetbrains Devnet 和 YouTrack 跟踪器，并记住在搜索中使用魔法词
clobber。然后安装 groovy-plug 并使用
StartBuildPrecondition设施其中管理依赖配置“读取”和 DeploySite 配置“写入”共享项目的事实。
（这不是一个完整的产品化解决方案，因此跟踪器项目保持打开状态）
编辑：我仍然不知道锁是否应该位于构建参数|系统属性下以及确切的 名称格式应该是，是
locks.writeLock.MYLOCKNAME（即，使用参考语法%system.locks.writeLock.MYLOCKNAME%显示在配置中）？其他令人困惑的问题是：如何管理由 writeLock 任务的构建完成所触发的构建读取访问 - 锁是否会被删除，直到下一个获取（这将允许另一个写入者进入） - 或者是否有必要将某些内容排队父母和孩子同时依赖？
Seems you go look on the Jetbrains Devnet and YouTrack tracker first and remember to use the magic word
clobberin your search.Then you install groovy-plug and use the
StartBuildPreconditionfacilitytherein to manage the fact that the dependent configs 'read' and the
DeploySiteconfig 'writes' the shared item.(This is not a full productised solution hence the tracker item remains open)
EDIT: And I still dont know whether the lock should be under Build Parameters|System Properties and what the exact name format should be, is it
locks.writeLock.MYLOCKNAME(i.e., show up in config with reference syntax%system.locks.writeLock.MYLOCKNAME%) ?Other puzzlers are: how does one manage giving builds triggered by build completion of a writeLock task read access - does the lock get dropped until the next one picks up (which would allow another writer in) - or is it necessary to have something queue up the parent and child dependency at the same time ?