我的团队使用团队城市用于持续集成。它将通过以下方式构建、测试和部署 Web 应用程序Web 部署到开发和质量保证 Web 服务器。棘手的部分是部署到生产 Web 服务器 - 我们的政策规定开发人员不能部署到生产，只有系统管理员可以。
我们目前的方法是让 TeamCity 构建一个 Web 部署包，管理员可以下载并安装在生产 Web 服务器上。但是，我们希望允许他们简单地单击构建配置上的“运行”，但我们不确定如何保护该按钮。
我们可以创建一个只有管理员才能访问的 TeamCity 项目，但我们还必须解决 Web Deploy 安全问题。Web Deploy 服务需要使用生产服务器上的本地管理员帐户进行身份验证。我们不希望开发人员能够访问构建脚本中的用户名/密码，也不希望每个构建代理都以此帐户运行，因为开发人员可以创建一个使用它来部署到生产的构建。
我一直没能找到有关 TeamCity 安全/部署最佳实践的资源，但我不认为我们是唯一一家遇到这种情况的公司。其他人如何管理自动部署安全？
答案1
使用角色和权限在 Teamcity 中，您可以拥有一个只有您的部署团队才能访问的项目。它可以有一个工件依赖性在主版本上，您甚至可以使用“上次固定的版本”，以便开发人员可以控制可用的内容。
我将安装一个能够部署到目标系统的构建代理，然后使用“兼容版本”TeamCity UI 中该代理的功能，使其仅与您的生产部署版本兼容。（当然，您还需要确保您的开发人员没有修改代理配置的权限。）
这是 Teamcity 使用 Agent 兼容配置选项的一个缺点：如果您离开您的其他将代理构建为与所有构建兼容，然后可以从其中一个代理尝试进行生产部署（如果可用）。我知道的唯一解决方法是将它们全部设置为仅运行“指定构建”，并将所有其他构建添加到其他代理。麻烦的是，如果您添加新构建，它将无法在任何地方运行，除非您明确将其添加为兼容。
还有另外几种方法可以使用构建配置中的代理要求将构建限制为仅在特定代理上运行。
一种是添加一个teamcity.agent.name等于您希望它在其上运行的代理名称的要求。（或者相反，不等于您不希望它在其上运行的代理名称）。
另一种是添加对环境变量的要求（存在或具有特定值），然后仅在您希望能够运行该构建的代理上设置该环境变量。
另一个可能的解决方案是安装两个 Teamcity，因为您实际上有两组不同的用户。您显然不能使用工件依赖项，但您始终可以使用以下 URL 获取给定构建的最新工件：*http://teamcity.server/repository/download/bt41/latest.lastSuccessful/setupfile.exe
在哪里：
bt41是 Teamcity 中的构建 ID（当您导航到任何构建时，您可以在 URL 中找到它）latest.lastSuccessful也可以是lastest.lastPinned“latest.lastFinished”，或者确切的版本号setupfile.exe是您想要从工件输出中抓取的文件（如果它未在顶层发布，这也可以是路径）
答案2
为了确保 Web 部署过程的安全，如果您在域中，则可以将 Web 部署设置为接受 Windows 身份验证，然后让 teamcity 构建代理以有权在 IIS 中部署的域用户身份运行。我已按此方式设置，并且您不需要在 Web 部署脚本中设置任何类型的密码。
为 Web 部署设置 Windows 身份验证：http://blogs.iis.net/carlosag/archive/2011/12/13/using-windows-authentication-with-web-deploy-and-wmsvc.aspx
编辑：
正如下面的评论所建议的，这里是链接内容摘要，以防链接断开：
默认情况下，在 Windows Server 2008 中，当您使用 Web 管理服务 (WMSVC) 和 Web 部署（也称为 MSDeploy）时，它将使用基本身份验证来执行部署。如果要启用 Windows 身份验证，则需要设置注册表项，以便 Web 管理服务也支持使用 NTLM。为此，请通过添加名为“已启用 Windows 身份验证”在HKEY_LOCAL_MACHINE\Software\Microsoft\WebManagement\Server下找到“Web管理服务”，并将其设置为1，如果Web管理服务已经启动，则该设置在服务重启后生效。
有关其他配置选项的详细信息，请参阅： http://technet.microsoft.com/en-us/library/dd722796(WS.10).aspx