azure-devops - TFS xaml build vs TFS vNext build vs Octopus Deploy 的可维护性

Question

我的问题是关于 vNext/Octopus 进程与基于 XAML 的进程的可维护性。或者更确切地说，因为不可能保持他们的理智让我相信我们正在做一些非常错误的事情。

鉴于：

• 微软推动逐步淘汰其 TFS XAML 构建以支持 vNext 构建
• Octopus Deploy 是一个流行的部署自动化框架
• 我们有许多基于 XAML 的构建，但开始移植到 vNext
• 使用 Octopus Deploy 自动部署

具体来说，我们在 QA 中进行了三种构建：

• 旧的基于 XAML 的编译生成生成要部署的工件
  • 最终只是构建代码，将其压缩并放置在众所周知的位置
• 新的 vNext 编译构建生成要部署的工件
  • 和上面一样
• 部署构建
  1. 每个部署环境的基于 XAML 的构建定义。这是特定部署的真实来源，包含所有配置 URL、连接字符串、证书指纹等。构建定义有 100 多个构建参数。每次设置新环境时，我们都会克隆现有的 XAML 构建定义并更改参数。
     • 此构建解压构建工件，根据配置参数生成所有 web/app 配置文件，并使用 octo.exe 启动带有大量参数的 Octopus Deploy 并等待结束
  2. 八达通部署流程
     • 从先前由 XAML 构建解包的构建工件创建 3 个包，以匹配三个部署区域 - Web 场、后台作业引擎集群和数据库
     • 将相关包裹递送至相关触手。
     • 触手解包并设置它们各自的包

因此，如果我们有 50 个部署环境，那么我们就有 50 个 XAML 部署构建，每个构建都捕获各自环境的上下文。但是 XAML 部署构建将部署工作委托给 Octopus，在这里我们被迫拥有 50 个 Octopus 项目 - 每个部署一个。

为什么会这样？我们研究了仅拥有一个 Octopus 项目的选项，但该项目的发布版本是什么？为了让我们能够在海量版本中导航，发布版本必须包括：

• 已部署代码的构建版本，例如55.0.18709.3
• 部署环境的名称，例如atwfm

使用上面的例子，这给了我们55.0.18709.3-atwfm，但有时我们想在同一个部署环境中部署相同的构建工件两次。但是唯一的 Octopus 项目已经有 release 了55.0.18709.3-atwfm，那么如何在不删除已经存在的 release 的情况下再次部署55.0.18709.3呢atwfm？

我们找不到解决方法，因此，我们每个部署都有 Octopus 项目。

这太疯狂了，因为 Octopus 项目更新起来很痛苦。假设我们需要添加一个步骤——在 50 个项目中进行。互联网上有很多建议使用自动化来编辑多个项目。一点都不理想。

vNext，顺便说一句，也有同样的问题。如果我要将现有的 XAML 构建移植到 vNext，我最终会得到 50 个 vNext 部署构建。如果我决定添加一个步骤，我需要在所有 50 个构建中都这样做！！！！

请注意，XAML 构建没有这个问题（尽管它们还有很多其他问题），因为它们的过程与参数是分开的。我可以修改一次工作流，所有 XAML 构建现在都使用新的流程更改进行更新。

我的问题是——人们如何使用 vNext 和 Octopus，因为我们的流程让我发疯。一定会有更好的办法。

编辑 1

我想澄清一下。我们有时想要两次部署相同的构建工件。我们不会重新编译它们并重用相同的版本。不。我们已经有了方便的构建工件，构建版本在工件内部烘焙。我们可能希望第二次将其部署到同一环境中，因为例如，该环境中的某些数据库配置错误，现在已修复，我们需要重新部署。这并不意味着我们可以重新运行已经存在的 Octopus 版本，因为修复可能涉及调整相应 XAML 部署构建定义的部署参数。因此，我们可能会被迫重新启动 XAML 部署构建，它永远不会编译代码。

编辑 2

首先，为什么我们从 TFS XAML 构建而不是从 Octopus 驱动部署？历史原因。起初我们没有八达通。部署是由我们的临时代码完成的。当我们介绍 Octopus 时，我们决定保留 XAML deploymenet 构建有两个原因：

1. 为了节省将具有所有大量部署参数的所有 XAML 部署构建迁移到 Octopus 的成本。也许这是一个错误的决定，也许我们可以自动化迁移。
2. 因为 TFS 有更好的工具来显示测试结果。部署可能以部署冒烟测试结束，其结果必须在某处发布。我们看不到 Octopus 如何帮助我们发布结果，TFS 可以。

为什么要重新部署？例如，部署参数之一是证书指纹。更新证书时，必须更改此参数（我们确实可以自动更新 XAML 构建参数）。但我们经常发现它已经使用错误的指纹进行部署。因此，我们修复了部署并重新部署。或者，我们发现已部署应用程序的一些奇怪行为，并希望重新部署一些额外的跟踪/调试功能。

Answer 1

这里有很多东西要解压，但我会试一试。

TL;DR 是您对版本进行版本控制的方式给您带来了所有痛苦。改变它，其他一切都会到位

让我们从头开始并向后工作。

Octopus Deploy 有一个环境的概念。这意味着您可以将同一个项目部署到多个环境并使用 Octopus 的范围机制来管理特定于环境的配置。

所以用你的例子。

从先前由 XAML 构建解包的构建工件创建 3 个包，以匹配三个部署区域 - Web 场、后台作业引擎集群和数据库

我在 Octopus 中为您的 50 个环境中的每一个设置了一个环境。（为了简单起见，我将在示例中使用 3 个环境，但无论您有多少环境，这些原则都适用）

在我的开发环境中，我有一个服务器，因此我创建了一个名为“Dev”的环境并为该特定服务器添加了触手。然后我用部署类型“Web”、“Job”、“Database”标记触手

然后我设置了一个包含 3 台服务器的测试环境，因此我创建了环境并添加了 3 台服务器。然后我用部署类型“Web”、“Job”、“Database”标记每个触手

最后我设置了生产环境。这有 5 个 Web 服务器、1 个作业服务器和 1 个数据库服务器。我将所有 7 个触手添加到环境中，并适当地标记它们。

现在我只需要 1 个项目即可部署到所有 3 个环境。在我的项目中，我有 3 个步骤。

步骤 1 部署网站

步骤 2 部署作业

步骤 3 部署数据库

我可以标记这些步骤中的每一个，以说明我想要部署哪种触手。现在，当我运行部署时，步骤上的标签和触手上的标签之间的链接意味着 Octopus 知道在哪里部署代码。

变量：您的变量可以限定为环境。因此，例如，如果您的开发环境数据库连接字符串是dev.database.net/Instance并且您的测试环境数据库连接字符串是，test.Database.net/Instance那么您可以在项目的变量部分中确定这些范围。如果您的 DNS 与您的环境名称一致，您甚至可以使用一些内置变量来更轻松地添加环境。IE${Octopus.Environment.Name}.Database.net/Instance

版本和版本号： 所以这就是我认为您的问题所在。将环境名称添加到版本并尝试使用相同版本创建多个版本基本上会给您带来所有痛苦。

使用上面的示例，这给了我们 55.0.18709.3-atwfm，但有时我们希望在相同的部署环境中部署相同的构建工件两次。但是唯一的 Octopus 项目已经有了 55.0.18709.3-atwfm 版本，那么如何在 atwfm 中再次部署 55.0.18709.3，而不删除已经存在的版本？

这里有几件事。在 Octopus 中，您可以轻松地从 UI 再次部署，但听起来您正在重建工件并尝试创建具有相同版本号的新版本。不要这样做！每个新版本都应该有一个独特且唯一的版本号/版本号。

我遵循的原则是“构建一次部署多次”

当您创建一个版本时，它需要一个版本号，然后此版本会流经环境。所以我构建了我的代码，它得到了一个版本号55.0.18709.3，然后我将它部署到 Dev。验证部署后，我想“推广”发布以进行测试，我可以在 Octopus 中执行此操作，也可以让 TFS 执行此操作。

所以我推广55.0.18709.3测试，然后推广。如果我需要知道哪个版本在哪个环境中，Octopus 通过仪表板或 API 告诉我。

最后，我可以使用 Build v.next 在我的环境中“协调”发布流程。

所以我的端到端过程看起来像。

构建 vNext 构建

• 编译
• 运行单元测试
• 包输出
• 发布包

构建 vNext 版本

• 调用 Octopus 以创建传递版本号的版本
• 可选择将版本部署到您生活中的第一个环境

现在，我在 Octopus 中拥有所需的一切，可以通过单个项目和特定于环境的配置部署到任何环境。

我可以将发布“部署”到特定环境，也可以将发布从一个环境“提升”到另一个环境。这可以在 Octopus UI 中轻松完成

或者我可以使用 TFS 中的 Octopus 插件创建一个“Promote”，并使用它来协调通过环境推广代码。

章鱼术语。创建发布 - 这会将 Octopus 中的工件和发布编号组合在一起，以创建一个不可变的事物，该事物将被部署到多个环境之一。

部署发布 - 将代码推送到特定环境的行为。

促进发布——一旦代码被部署到单个环境中，就可以将它们提升到其他环境中

如果您有特定的环境序列，那么您可以使用 Octopus 的“生命周期”功能来强制执行该工作流程。但这是另一天的话题！

EDIT1 响应

我认为编辑不会改变我的答案，您可以根据需要多次重新部署相同的版本。您不能做的是创建具有相同版本号的新版本。您可能想要解耦这些步骤，您能否添加更多关于 XAML 构建中的哪些更改的详细信息？您可以在发布中更改变量，您可以在 octopus 中更新它们，然后重新部署

编辑 2 回应

这让事情变得更清楚了。我认为您需要接受打击并将参数迁移到 Octopus。它的变量管理比 XAML 构建要好得多，尽管构建 vNext 与 Octopus 相当，但在 Octopus 中进行配置更有意义。随着 XAML 构建即将推出，现在移动这些东西是有意义的。虽然这可能需要大量工作，但最终您的工作流程会更加繁琐，并且您可以真正利用 Octopus 的强大功能。

测试结果点。我同意这更适合构建 vNext，因此此时您将使用 build vNext 作为您的 Orchestrator，并使用 Octopus Deploy 作为您的发布管理工具。

这个过程看起来像

构建 vNext

• 编译代码。
• 运行单元测试
• 运行 Octopack
• 发布包
• 调用 Octopus 并创建发布
• 调用 Octopus 部署到“Dev”
• 运行冒烟测试
• 运行集成测试
• 调用“Selenium”来运行 Run UI 测试
• 致电八达通推动发布到“测试”
• 运行冒烟测试
• 运行集成测试
• 调用“Selenium”来运行 Run UI 测试
• 调用 Octopus 以促进发布到“生产”（可能带有手动神经支配）
• 运行冒烟测试
• 运行集成测试
• 调用“Selenium”来运行 Run UI 测试