jru*_*ell 7 security deployment teamcity
我的团队使用TeamCity进行持续集成。它将通过Web Deploy构建、测试和部署 Web 应用程序到 dev 和 qa Web 服务器。棘手的部分是部署到生产 Web 服务器 - 我们的政策规定开发人员不能部署到生产，只有系统管理员可以。
我们目前的方法是让 TeamCity 构建一个 Web 部署包，管理员可以下载并安装在生产 Web 服务器上。但是，我们希望允许他们在构建配置上简单地单击“运行”，但我们不确定如何保护该按钮。
我们可以创建一个只有管理员才能访问的 TeamCity 项目，但我们还必须解决 Web 部署安全问题。Web Deploy 服务需要使用生产服务器上的本地管理员帐户进行身份验证。我们不希望开发人员访问构建脚本中的用户名/密码，也不希望每个构建代理都以此帐户运行，因为开发人员可以创建一个构建，使用它来部署到生产环境。
我没有太多运气找到有关 TeamCity 安全/部署最佳实践的资源，但我无法想象我们是这种情况下唯一的公司。其他人如何管理自动化部署安全？
使用Teamcity 中的角色和权限，您可以拥有一个只有您的部署团队有权访问的项目。它可以对主构建具有工件依赖性，您甚至可以使用“最后固定构建”，以便开发人员可以控制甚至可用的内容。
我会安装一个能够部署到目标系统的构建代理，然后在 TeamCity UI 中使用该代理的“兼容构建”功能，使其仅与您的生产部署构建兼容。（当然，您还需要确保您的开发人员无权修改代理配置。）
这是 Teamcity 使用代理兼容配置选项的一个缺点：如果您将其他构建代理保留为与所有构建兼容，则可以从其中一个免费尝试生产部署。我所知道的唯一解决方法是将它们全部设置为仅运行“指定的构建”并将所有其他构建添加到其他代理。痛苦的是，如果您添加一个新版本，它将无法在任何地方运行，除非您专门将其添加为兼容版本。
还有另外几种方法可以使用构建配置中的代理要求将构建限制为仅在特定代理上运行。
一种是添加一个要求，该要求teamcity.agent.name等于您希望它在其上运行的代理名称。（或者相反，不等于您不希望它运行的那个）。
另一种方法是添加对环境变量的要求（存在或具有特定值），然后仅在您希望能够运行该构建的代理上设置该环境变量。
另一种可能的解决方案是安装两次 Teamcity，因为您实际上拥有两组不同的用户。您显然不能使用工件依赖项，但您始终可以使用以下网址获取给定构建的最新工件：*http://teamcity.server/repository/download/bt41/latest.lastSuccessful/setupfile.exe
在哪里：
bt41 是 Teamcity 中的构建 ID（当您导航到任何构建时，您可以在 URL 中找到它）latest.lastSuccessful 也可以是lastest.lastPinned，`latest.lastFinished，或确切的内部版本号setupfile.exe 是您要从工件输出中获取的文件（这也可以是路径，如果它未在顶级发布）