在两个不同的团队之间共享TeamCity

Question

我们的团队拥有TeamCity服务器的完整许可证，以及7个其他代理商。另一个不相关的团队已达到他们的免费TeamCity许可证的限制，并正在关注我们的许可证。

认为使用相同的企业许可证运行两个团队是一个好主意的权力，这意味着我们将在同一台服务器上托管TeamCity配置，并共享代理或以某种方式将一些代理分配给一个团队一些到另一个。

我担心的一个问题是配置代理仅接受某些构建很困难 - 我们的团队有数百个构建配置，我们一直在创建新的构建。要将代理限制为某些构建，您必须完全指定白名单。因此，维护代理商，以便我们充分利用一些代理商，而其他团队充分利用他们的代理商将是一种痛苦。另一方面，只使用一个代理池意味着你现在有优先权和饥饿等参数。

有没有人有这方面的经验？这是一个可行的解决方案吗？如何配置代理为特定团队保留它们？如何配置服务器，以便每个团队只能看到自己的项目，构建配置和代理？基本上我们想要的是完全分离项目，只使用相同的TeamCity服务器和代理。

作为一种直觉，它看起来不是一个好主意......

编辑：顺便说一句，哈德森做得更好吗？象牙塔建筑师希望我们从TeamCity改为Hudson，因为其他人正在使用Hudson。如果我告诉他们这个共享TeamCity将不起作用，哈德森阵营可能会用它作为一个击败我们的棍子。喜悦。

Answer 1

不确定您正在使用的TeamCity版本，但新发布的TeamCity v7.0现在具有新的代理池功能，可以更轻松地分发代理。它可能对您感兴趣，请查看What's New section或Agent Pools docs以获取更多信息。

我遇到了类似的问题，我们的两个部门开始共享同一个TeamCity实例，以节省额外许可证的费用。我必须承认，除了我们的代理人现在两倍的忙碌之外我们没有任何问题。

我在“全局设置”页面上启用了每个项目的权限并创建了2个用户组，一个用于“我们”，另一个用于“他们”。然后，您可以相应地配置每个组的角色。如果一个组没有项目的Project Viewer角色，那么它就不会出现 - 这是一个只向组显示必要项目的好方法;但是还有很多其他角色选择可供使用。

我从未使用过Hudson，所以无法比较。我应该尝试一下，但因为我总是和TC相处得很好我也没有理由。

Answer 2

您可以在代理程序要求部分中的每个构建的构建配置中对某个代理程序运行构建，从而将任何构建配置限制为某些代理程序。 例如，如果一个团队的代理是teamcity1，您可以指定：

system.agent.name  does not equal teamcity1

因此它永远不会在该代理上运行。 这样，您至少可以复制构建配置，并且它们将在没有小提琴代理配置的情况下在单独的代理上运行。

Answer 3

另一个团队可以创建一个新的Teamcity服务器，它将拥有自己的一组新的免费构建配置和代理。

Answer 4

我们不再这样做，但我们过去常常将我们的代理分成伪池，因此我们可以预留一些用于编译，其他用于自动化测试（因为自动测试作业可以淹没网格）。我们向测试代理添加了“can_run_tests”属性，并使这些构建需要该属性作为代理条件。它工作得很好，而且你可以为一组云代理烘焙AMI。

我们现在所做的是在不同的AMI上进行编译和测试构建需要，这基本上是相同的。