多阶段部署的 Team City 最佳实践是啥？

Posted 2023-03-04

【中文标题】多阶段部署的 Team City 最佳实践是啥？

【英文标题】：What are the Team City best practices for multistage deployment?多阶段部署的 Team City 最佳实践是什么？

【发布时间】：2011-12-08 00:13:14

【问题描述】：

我们有 3 个环境：

开发：

Team City 在此处部署，用于主干上的 Subversion 提交。

暂存：

用户接受在此处完成，在作为发布候选的版本上。

生产：

当UAT通过时，通过代码集部署在这里。

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

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

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

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

更新：

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

更新 2

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

是否有任何方法可以使用 Team City 自动部署到暂存/生产环境？

【问题讨论】：

这里有点晚了，但看起来你真的会从定义的DevOps toolchain 中受益，而且绝对是一个应用程序发布自动化工具。这正在成为标准——使用 CI 的 TeamCity 等工具并链接到 ARA 工具以进行协调和部署。 en.wikipedia.org/wiki/Application_release_automation

【参考方案1】：

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

---

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

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

以社交方式处理。每个人都知道他们的责任是什么，并且你不会运行你不应该运行的东西。如果您这样做，它会被审核并追溯到您。只要有成熟、明确的责任概念并且没有禁止它的合规要求，就可以正常工作。 创建单独的项目。我不喜欢这样做，但它确实解决了问题。您仍然可以使用来自另一个项目的工件，这意味着您最终会得到一个包含构建的项目，这些构建部署到您很高兴所有开发人员都可以访问的环境中，而另一个项目则部署到敏感环境中。不利的一面是，如果生产构建失败，您可能需要支持的人将无法访问它！

---

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

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

这是否回答了您的问题？还缺什么吗？

【讨论】：

感谢您的出色回答。我现在对权限非常清楚。我将不得不阅读您链接到的关于配置转换的 2 部分系列。不幸的是，我们目前只有很少的 .NET 4.0 项目。我们的大多数应用程序都是 2.0 框架，我们依靠非常脆弱和幸运的“不要复制 web.config”来管理配置文件。因此，我只有一个简单的 NAnt（因为它对我来说似乎比 MSBuild 更容易）脚本来删除旧文件并用新文件复制，不包括 web.config。

请记住，您仍然可以将项目保留在 .NET 2 中并使用配置转换，您只需要拥有 Visual Studio 2010。这可能是您最好的中间立场.

有趣...我们现在让它们在 2010 解决方案中运行，但由于某种原因，我无法弄清楚如何使配置转换工作。我以为是因为它运行在 2.0 框架中，而不是 4.0。

在 VS2010 中，只需右键单击您的 web.config 并选择“添加配置转换”。此功能独立于 .NET 版本。

好的，所以我的问题是这个项目是一个网站项目，而不是 Web 应用程序。显然配置转换在那里不起作用，这并不奇怪。

【参考方案2】：

我们还使用 TeamCity 作为构建服务器，所以让我解释一下我们的设置。 我们有 4 个环境

Dev 用于验证服务器环境中的提交的开发 用于测试目的的 QA 部署检查和一些 UAT 的暂存 生产

我们仅使用 TeamCity 部署到开发（每晚构建）和 QA（按需）。 Dev 构建使用主干分支，而 QA 构建使用用于 RC 的不同分支。

部署到暂存和生产由 IT 团队管理，因此不是自动化的。

我们所做的是使用 TeamCity 从 QA 构建中生成工件。工件是为暂存/生产部署发送的部署工具包。

也就是说，我不确定 TeamCity 是否可以让您完全控制哪个构建可以提升到哪个环境。我们基本上通过分支在 SVN 端控制它，并为这些分支提供不同的构建。你可以（应该）以同样的方式管理它。因此，您可以确保部署了什么。

我了解您的需求可能与我们的略有不同，但我希望这将有助于您找到最佳设置。

【讨论】：

我的同事和我正在讨论使用 QA 分支，然后使用工件处理暂存/生产部署是有意义的。我仍然非常希望能够只授予特定的一组人员权限来运行生产部署的构建，这样我们就有了生产部署的良好历史作为 Team City 内部的日志。一想到Subversion中的所有合并就已经让我头疼了！ :) 我们正在尝试迁移到 DVCS...这将使这种设置变得更加容易。

【参考方案3】：

我认为您可能想查看Octopus Deploy 或BuildMaster 之类的内容。它们为您尝试自动化的部署实践提供了一个很好的结构。这两种工具都很好地与 TeamCity 集成。

基本上，您将继续使用 TeamCity 进行 CI，您也可以继续使用 TeamCity 部署到您的开发环境中，但您可以使用其中一种部署工具将（现有）构建升级为暂存和生产。

编辑 2014-02-05 - 更新

BuildMaster 的制造商为其 NuGet 服务器工具 ProGet 提供了一个新的部署功能 - ProGet Deploy。它与 Octopus Deploy 非常相似，虽然我自己还没有玩过，所以 Octopus 可以更好地可视化哪些版本已部署到哪些环境；由于这个重要功能，我仍然使用 BuildMaster。

另外，我目前同时使用 TeamCity、BuildMaster 和 ProGet，我再也不想回到没有自动构建的状态。目前，我所有的应用程序都是通过 BuildMaster 构建和部署的。我所有的图书馆项目都在 TeamCity 中构建并部署到 ProGet。能够通过 NuGet 基础架构管理我的内部依赖项是不错。