我的问题是有关vNext / Octopus进程与基于XAML的进程的可维护性。或更确切地说，不可能合理维护它们使我相信我们做错了什么。
给出：
具体来说，我们在质量检查中进行了三种构建：
因此，如果我们有50个部署环境，那么我们有50个XAML部署版本，每个版本都捕获各自环境的上下文。但是XAML部署版本将部署工作委托给Octopus，并且在这里我们被迫拥有50个Octopus项目-每个部署一个。
为什么会这样？我们研究了仅拥有一个八达通项目的选择，但是该项目的发行版是什么？为了使我们能够浏览大量的发布，发布版本必须包括：
55.0.18709.3 atwfm 使用上面的示例，我们得到了55.0.18709.3-atwfm，但是有时我们想在相同的部署环境中两次部署相同的构建工件。但是唯一的Octopus项目将已经具有55.0.18709.3-atwfm版本，那么如何在不删除现有版本的情况下再次在55.0.18709.3中部署atwfm？
我们找不到解决方法，因此，每个部署中都有一个Octopus项目。
这绝对疯狂，因为八达通项目很难更新。假设我们需要添加一个步骤-在50个项目中进行。互联网上有很多建议使用自动化来编辑多个项目。一点都不理想。
vNext，顺便说一句，有同样的问题。如果要将现有的XAML构建移植到vNext，我将得到50个vNext部署构建。如果我决定添加一个步骤，则需要在所有50个版本中都使用它！！！
请注意，XAML构建不存在此问题（尽管还有许多其他问题），因为它们的过程与参数分开。我可以修改工作流程一次，现在所有XAML构建都将通过新的流程更改进行更新。
我的问题是-人们如何使用vNext和Octopus，因为我们的过程使我发疯。必须有更好的方法。
编辑1
我想澄清一下。 我们有时想两次部署相同的构建工件。我们不会重新编译它们并重新使用相同的版本。否。我们已经有了构建工件，并且在工件内部生成了构建版本。我们可能想第二次将其部署到同一环境中，因为例如该环境中的某些数据库配置错误，现在已修复，我们需要重新部署。这并不意味着我们可以重新运行已经存在的Octopus版本，因为该修复程序可能涉及调整各个XAML部署构建定义的部署参数。因此，我们可能被迫重新启动从未编译代码的XAML部署版本。
编辑2
首先，为什么我们从TFS XAML构建而不是从Octopus驱动部署？历史原因。我们最初没有八达通。部署是通过我们的临时代码完成的。引入Octopus时，我们决定保留XAML deploymenet构建的原因有两个：
为什么要重新部署？例如，部署参数之一是证书指纹。证书更新后，必须更改此参数（我们确实具有用于更新XAML构建参数的自动化功能）。但是我们经常发现它已经使用错误的指纹进行了部署。因此，我们修复了部署并重新部署。或者，我们发现部署的应用程序有些奇怪的行为，并希望通过一些额外的跟踪/调试功能来重新部署。
答案 0 :(得分：3)
这里有很多要解压的东西，但我会尝试的。
TL; DR发行版本的方式导致了您的所有痛苦。更改它，其他所有内容都将放置在适当位置
让我们从结尾开始，然后倒退。
Octopus Deploy具有环境的概念。这意味着您可以将同一项目部署到多个环境，并使用Octopus的范围界定机制来管理特定于环境的配置。
因此，以您的示例为例。
从先前由 XAML构建可匹配部署的三个区域-Web场，背景 作业引擎集群和数据库
我在八达通中为您的50个环境中的每个环境设置了一个环境。 （在示例中，我将使用3种环境来简化它，但是无论您有多少种环境，原则都适用）
在我的开发环境中，我有一台服务器，因此我创建了一个名为“ Dev”的环境，并为该特定服务器添加了触手。然后，我用部署类型“ Web”，“ Job”，“ Database”标记触手
然后，我设置一个具有3个服务器的测试环境，因此我创建环境并添加3个服务器。然后，我用部署类型“ Web”，“ Job”，“ Database”标记每个触手
最后，我设置了生产环境。它有5个Web服务器，1个作业服务器和1个数据库服务器。我将所有7个触手添加到环境中，并对其进行了适当的标记。
现在我只需要一个项目即可部署到所有3个环境。在我的项目中，我有3个步骤。
第1步部署网站
第2步部署作业
第3步部署数据库
我可以标记每个步骤，以说出要部署到哪种触手。现在，当我运行部署时，步骤上的标签与触手上的标签之间的链接意味着Octopus知道将代码部署在何处。
变量：您的变量可以在环境范围内使用。因此，例如，如果您的开发环境数据库连接字符串为dev.database.net/Instance，而测试环境数据库连接字符串为test.Database.net/Instance，则可以在项目的变量部分中确定它们的范围。如果您的DNS与您的环境名称一致，您甚至可以使用一些内置变量来简化添加环境。即${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进行测试，然后继续生产。如果我需要知道哪个环境中的哪个发行版，Octopus会通过仪表板或API告诉我。
最后，我可以使用Build v.next在整个环境中“协调”发行流程。
所以我的端到端过程看起来像。
构建vNext构建
构建vNext版本
我现在拥有八达通所需的一切，只需一个项目和我的环境特定的配置即可部署到任何环境。
我可以将发行版“部署”到特定环境，也可以将发行版从一个环境“升级”到另一个环境。您可以在八达通用户界面中轻松完成此操作
或者我可以使用TFS中的Octopus插件创建一个“ Promote”，并使用它来协调环境中的代码提升。
章鱼术语。 创建发布-将八达通中的工件和发布编号汇总在一起，以创建一个不可变的事物，该事物将被部署到多个环境之一。
部署发行版-将代码推送到特定环境的行为。
升级版本-将代码部署到单个环境中后，可以将其升级到其他环境中
如果您有特定的环境序列，则可以使用Octopus的“生命周期”功能来强制执行该工作流程。但这是另一天的话题！
EDIT1响应
我认为修改不会改变我的答案，您可以根据需要多次重新部署同一发行版。您不能做的是使用相同的版本号创建一个新发行版。您可能希望取消这些步骤的耦合，是否可以添加有关XAML构建中哪些更改的更多详细信息？您可以在发行版中更改变量，可以在章鱼中更新它们，然后重新部署
编辑2回复
这使事情更加清楚。我认为您需要按一下，然后将参数迁移到Octopus。它的变量管理比XAML构建好得多，尽管构建vNext与Octopus相当，但在Octopus中进行配置更有意义。由于XAML构建即将淘汰，现在就可以移走这些东西了。尽管可能需要进行很多工作，但最后您将拥有更加繁琐的工作流程，并且您可以真正利用Octopus的强大功能。
测试结果点。我同意这更适合于构建vNext，因此在这一点上，您将使用构建vNext作为Orchestrator，并使用Octopus Deploy作为发布管理工具。
该过程看起来像
构建vNext