deployment - Team City 多阶段部署的最佳实践是什么？

Question

我们有 3 个环境:

• 开发:Team City 在此部署，以在主干上进行 Subversion 提交。
• 暂存:用户接受是在此处针对候选版本的构建完成的。
• 生产:当UAT通过时，通过的代码集部署在此处。

我们正在使用 Team City，并且仅在我们的开发环境中进行持续集成设置。我不想为 Team City 所做的每个开发部署保存工件。我希望指定人员能够触发构建配置，将某个成功的开发部署部署到我们的登台服务器。

然后，我希望每个临时部署都能保存工件。当暂存部署通过 UAT 时，我想将该包部署到生产环境。

我不知道如何在 Team City 中进行设置。我正在使用版本 6.5.4，并且我知道有一个“升级...”操作/触发器，但我认为这取决于保存的工件。我不想每次都将开发部署保存为工件，但我确实希望运行暂存部署的人员能够指定要部署到暂存的成功开发部署。

我知道可能有多种方法可以做到这一点，有最佳实践吗？您的设置是什么？为什么推荐它？

更新:

到目前为止我有一个答案，这是我们内部考虑过的一个想法。我真的很想知道是否有人有一种通过 Team City 本身部署到临时/生产环境的自动化方法，只有具有特定角色/权限的人才能将部署脚本运行到生产环境，而不必手动处理任何问题一种神器包。有人吗？

更新2

我还有 1 天的时间来发放赏金，我认为下面的答案没有回答我的问题，但重读后我发现我的问题不是我想象的那样。

是否有任何方法可以使用 Team City 对临时/生产环境进行某种自动化部署？

Answer 1

我认为您实际上在这里问了两个不同的问题；一个是关于控制对 TeamCity 构建的访问权限，另一个是关于工件管理的后勤工作。

<小时/>

关于权限，我假设您所说的“只有具有特定角色/权限的人才能将部署脚本运行到生产环境”，您对 Julien 的回应是您可能不希望开发人员直接部署到生产环境，但您确实希望他们能够看到项目中的其他构建。这也可能类似于 Julien 的场景，当时 IT 部门将流程从 TeamCity 中“离线”(要么是这样，要么只是 IT 部门在做 IT 部门所做的事情，并坚持要求他们必须使用一个单独的、完全低效的流程，因为“这就是我们做事的方式”) “- 别让我开始说这个!)

问题很简单，TeamCity 中的所有权限都应用于项目，而不是构建，因此，如果您有一个包含所有构建的项目，则没有能够将权限粒度应用于开发与生产构建。我之前用两种方式处理过这个问题:

1. 以社交方式处理此事。每个人都知道自己的责任是什么，并且你不会做不该做的事情。如果您这样做，系统会对其进行审核并可追溯到您。当成熟、有清晰的责任观念并且不存在禁止这样做的合规要求时，工作就很好。
2. 创建单独的项目。我不喜欢这样做，但它确实解决了问题。您仍然可以使用其他项目中的工件，这意味着您最终会得到一个项目，其中包含部署到您希望所有开发人员访问的环境的构建，而另一个项目则部署到敏感环境。缺点是，如果生产构建失败，您可能需要支持的人将无法访问它!

<小时/>

关于工件管理，在开发版本中保留它们没有问题，只需定义一个清理策略，如果您担心容量，则仅保留最后 X 版本中的工件。许多人希望确定他们将相同的编译输出部署到每个环境，这意味着一旦构建它，您希望保留它以供以后使用。

从开发部署中获得这些工件后，您可以通过单独的构建将它们重新部署到其他环境。您将遇到配置转换问题(假设您正在使用它们)，但请阅读 this 2 part series关于如何解决这个问题的一些想法(我还没有详细了解它，但我相信他走在正确的道路上)。

这能回答你的问题吗？还有什么遗漏的吗？