Azure devops TFS xaml构建与TFS vNext构建与Octopus部署的可维护性

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

鉴于：

微软推动逐步淘汰其TFS XAML版本，以支持vNext版本 Octopus Deploy是一个流行的部署自动化框架 我们有许多基于XAML的构建，但开始移植到vNext 使用Octopus Deploy自动进行部署 具体来说，我们在QA中有三种构建：

旧的基于XAML的编译构建生成要部署的构件 最终只需构建代码，将其压缩并放置在一个众所周知的位置 新的vNext编译生成要部署的工件 同上 部署构建 每个部署环境基于XAML的生成定义。这是特定部署的真实来源，包含所有配置URL、连接字符串、证书指纹等。。生成定义有100多个生成参数。每次设置新环境时，我们都会克隆现有的XAML构建定义并更改参数。 此构建将解压构建工件，根据配置参数生成所有web/app配置文件，并使用octo.exe启动Octopus部署，并使用大量参数等待结束 八达通部署流程 从先前由XAML构建解包的构建工件创建3个包，以匹配三个部署区域—web场、后台作业引擎集群和数据库 将相关包传送到相关触手。 触手打开并设置各自的包装 因此，如果我们有50个部署环境，那么我们有50个XAML部署构建，每个构建都捕获各自环境的上下文。但是XAML部署构建将部署工作委托给Octopus，这里我们被迫有50个Octopus项目——每个部署一个

为什么会这样？我们研究了只拥有一个八达通项目的选择，但这类项目的发布版本是什么？为了使我们能够在数以百万计的发行版中导航，发行版必须包括：

部署代码的内部版本，例如55.0.18709.3 部署环境的名称，例如atwfm 使用上面的示例，我们得到了55.0.18709.3-atwfm，但有时我们希望在相同的部署环境中部署相同的构建工件两次。但是唯一的八达通项目已经有了55.0.18709.3-atwfm版本，那么如何在不删除现有版本的情况下再次在atwfm中部署55.0.18709.3呢

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

这绝对是疯狂的，因为八达通项目是一个痛苦的更新。假设我们需要在50个项目中添加一个步骤。互联网上有很多关于使用自动化编辑多个项目的建议。一点也不理想

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

注意，XAML构建没有这个问题，但是它们还有很多其他问题，因为它们的过程与参数是分开的。我可以修改工作流一次，所有XAML构建现在都会随着新流程的更改而更新

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

编辑1

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

编辑2

首先，为什么我们要从TFS XAML构建驱动部署，而不是从Octopus驱动部署？历史原因。起初我们没有章鱼。部署是由我们的特殊代码完成的。当我们推出Octopus时，我们决定保留XAML deploymenet版本，原因有两个：

为了节省将所有XAML部署构建和所有gazillion部署参数迁移到Octopus的成本。也许这是一个错误的决定，也许我们可以自动化迁移。 因为TFS具有更好的显示测试结果的功能。部署可能以部署烟雾测试结束，其结果必须在som上公布 ewhere。我们看不到八达通如何帮助我们发布结果，TFS可以。

---

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

这里有很多东西需要解包，但我会尝试一下

TL；博士，这是你发布版本的方式给你带来的所有痛苦。改变这一点，其他一切都会到位

让我们从结尾开始，然后倒转

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

所以用你的例子

从先前由 XAML构建以匹配三个部署区域—web场、后台 作业引擎集群与数据库

我为您的50个环境中的每一个设置了一个八达通环境。在本例中，我将使用3个环境来保持简单，但无论有多少个环境，原则都适用

在我的Dev环境中，我只有一台服务器，因此我创建了一个名为Dev的环境，并为该特定服务器添加触手。然后我用部署类型Web、作业和数据库标记触手

然后我设置了一个测试环境，它有3台服务器，所以我创建了环境并添加了3台服务器。然后，我用部署类型Web、作业和数据库标记每个触手

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

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

步骤1部署网站

步骤2部署作业

步骤3部署数据库

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

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

发布和版本号：所以我认为问题出在这里。将环境名称添加到发行版中并尝试创建具有相同版本的多个发行版基本上会给您带来所有的痛苦

使用上面的例子，我们得到55.0.18709.3-atwfm，但是 有时我们希望在同一个系统中部署相同的构建工件 部署环境两次。但唯一的八达通项目是 已经发布了55.0.18709.3-atwfm，那么如何部署呢 是否再次在atwfm中使用55.0.18709.3，而不删除现有版本

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

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

当您创建一个版本时，它需要一个版本号，然后该版本在环境中流动。因此，我构建了我的代码，它的版本号为55.0.18709.3，然后我将其部署到Dev。当部署得到验证后，我希望升级该版本以进行测试，我可以从Octopus中执行此操作，也可以让TFS执行此操作

因此，我将55.0.18709.3升级为测试版，然后升级到prod。如果我需要知道哪个版本在哪个环境中，Octopus会通过仪表板或API告诉我这一点

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

所以我的端到端流程看起来像

构建vNext构建

编写 运行单元测试 包输出 发布包 构建vNext版本

通过输入版本号，呼叫Octopus创建发布 可以选择将该版本部署到您生活的第一个环境中 我现在有了Octopus中所需的一切，可以通过单个项目和特定于环境的配置部署到任何环境

我可以将该版本部署到特定环境，也可以从 从一个环境到另一个环境。这可以在八达通用户界面内轻松完成

或者，我可以在TFS中使用Octopus插件创建一个升级，并使用该插件在环境中协调代码的升级

章鱼术语。 createrelease——这将八达通中的工件和发行号结合起来，创建一个不可变的东西，它将被部署到一个或多个环境中

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

升级发布-一旦代码部署到单个环境中，就可以将其升级到其他环境中

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

EDIT1响应

---

我认为编辑不会改变我的答案，您可以根据需要多次重新部署同一版本。您不能使用相同的版本号创建新版本。您可能希望解耦这些步骤，您是否可以添加更多关于XAML构建中的更改的细节？您可以在发布中更改变量，也可以在八达通中更新变量，然后重新部署

编辑2响应

这让事情更清楚了。我认为你需要采取行动，并将参数迁移到八达通。它的变量管理要比XAML构建好得多，尽管构建vNext可以与Octopus相媲美，但使用Octopus进行配置更有意义。随着XAML构建即将推出，现在移动这些东西是有意义的。虽然这可能是一个很大的工作，在最后你会有一个非常窒息的工作流程，你可以真正利用八达通的力量

测试结果表明了这一点。我同意这更适合构建vNext，因此在这一点上，您将使用构建vNext作为您的编排器，使用Octopus部署作为您的发布管理工具

这个过程看起来像

构建vNext

编译代码。 运行单元测试 跑八达通 发布包 呼叫八达通并创建释放 呼叫Octopus以部署到开发人员 运行烟雾测试 运行集成测试 调用Selenium运行UI测试 打电话给八达通以促进测试的发布 运行烟雾测试 运行集成测试 调用Selenium运行UI测试 打电话给章鱼，也许通过人工神经支配来促进生产 运行烟雾测试 运行集成测试 调用Selenium运行UI测试

---

一种可能的解决方案是只构建一次包，要做到这一点，您必须找到一种方法，将特定于环境的配置设置与构建过程解耦，并在部署时注入环境配置。我认为编辑不会改变我的答案，您可以根据需要多次重新部署同一版本。您不能使用相同的版本号创建新版本。您可能希望解耦这些步骤，您是否可以添加更多关于XAML构建中的更改的细节？你可以，你可以用八达通更新它们，然后重新部署Edit2，投票结果接近的原因是+谢谢你花时间。非常感谢。我刚刚添加了编辑1，以澄清一些可能影响您答案的内容。您是否能够对其进行相应的检查和更改？