VSTS+八达通部署?为什么我看到很多CI/CD设置同时使用这两种设置

Question

我是一名过渡到Devops的开发人员。通过观察，我注意到许多开发商店已经开始使用Octopus Deploy和Azure Devops Services(AzDo，以前的VSTS)，或者他们正在启动新的项目来设置Devops-ci/cd管道，并指定使用这两种工具。

我已经对这两种工具进行了一些快速培训，尽管它们并不完全相同，但AzDo似乎提供了与Octopus Deploy相同的所有功能。

所以，我的问题是，如果一家公司已经在使用AzDo进行大部分版本控制，或者任何与CI/CD管道相关的东西，你为什么要使用Octopus？使用八达通进行构建并部署到AzDo有什么好处？

注意，我对Devops非常非常陌生。我之所以这么问，是因为在"10000英尺的视野"下，如果你已经在使用AzDo，那么章鱼似乎没有任何理由。我提到八达通部署的名字，因为我看到它经常出现。然而，我认为可能还有其他工具可以实现自动构建和部署的相同目的，也可以与AzDo集成。然而，AzDo提供了内置的构建和部署。为什么要分开工作？

Answer 1

让我先介绍一下为什么我喜欢使用VSTS:进行构建和部署

• 端到端的相同权限
• 端到端构建和部署的视线

我喜欢Octopus Deploy而不是VSTS Release的原因：

• 上传软件包/工件的能力
  • 外部软件包可能是为特定版本部署的一次性软件包
• 目标定义
  • 创建要部署到的目标或服务器时，可以将目标添加到一个或多个环境中，并为目标分配标签/角色。这是什么意思？更灵活的服务器定义，而不是将严格的Agent定义为池或将服务器定义为部署组，您可以允许一个目标跨越多个(即：一个测试服务器，它跨越您的开发和测试环境，并且只在为该角色定义的步骤上触发)。我知道你可以在VSTS中完成类似的事情，但在我看来，这要麻烦得多
• 变量定义
  • 变量可以在全局级别分组，并按特定的管道/过程分组(该部分类似于VSTS)。变量也可以按环境或角色分组或scoped(如上所述)，因此每个环境中每个角色可以有不同的变量值；具有超颗粒性和柔韧性。如果您有一个带有连接字符串的后端服务器，并且可能有两个内容传递节点(角色-content delivery)，它们的值与后端服务器略有不同，那么这就派上了用场。目前，我不知道(除了创建新的环境)如何在VSTS中实现同样的目标
• 流程定义
  • 以上所有内容都包含在Octopus Deploy的流程定义中。超灵活和细粒度的变量和目标定义使您能够专注于实际的部署过程，而不是拘泥于UI的细微差别及其局限性。一个例子是定义一个过程，其中第一步是从中央服务器中取出负载平衡器中的某些东西，第二步将代码部署到交付服务器一，第三步重新放入lb，第四步从从中央服务器调用的lb中取出节点二，第五步将代码配置到节点二，最后一步重新放入负载平衡器。我意识到这是一个非常简单的假设，但在Octopus Deploy中，它是一个经过过滤以在特定角色上执行的稳定过程，在VSTS中，你必须将其分解为不同的代理阶段，可能还有管道

以上确实是我在VSTS发布上使用Octopus Deploy的最大要点。现在，为什么有人会使用VSTS来构建，而使用OD来发布/部署呢？其中有很多不同的因素，有些是企业驱动因素，比如拥有通过MSDN处理权限的企业git客户端。有时，这是一个项目管理驱动因素，将工作项紧密地绑定到提交和构建中，但OD以免费/最低的成本带来了额外的灵活性。

希望这有助于揭示为什么有些人会跨越溪流并同时使用VSTS和OD。

Answer 2

已经提出了很多好的观点，但这实际上取决于您需要什么。我敢说，在发布管理真正成为一种东西之前，我们很多人就开始使用八达通了。

我们使用VSTS进行所有源代码控制和构建，然后通过八达通处理所有部署。

当我们开始评估工具时，VSTS没有可供部署的东西。即使是现在，他们仍然在功能集中扮演追赶章鱼的角色。

如果您正在进行真正的多租户和多环境部署，我不认为VSTS真的能与之相比。我们正在与大约30名租户一起使用八达通，有些在Azure上，有些在内部部署。我们混合部署了web和桌面应用程序。我们甚至使用Octopus来部署一些遗留的VB6和winforms应用程序。

• 多租户(对我们来说至关重要)

  • VSTS不久前添加了部署组，听起来与实现多租户之前的Octopus Environments非常相似。在Octopus拥有真正的多租户之前(现在已经有一段时间了)，人们会通过为每个租户创建不同的环境来解决这个问题，比如"CustomerA-Dev"、"CustomerA-Prod"等。现在，您只需要拥有Dev/Test/Prod环境，每个租户都可以拥有适用于这些单独环境的变量

• 支持

  • 文档非常好，而且非常容易启动和运行
  • 有几次我需要联系八达通的人，他们的回答非常迅速，也很有知识

• 可用性

  • 拥有八达通仪表板，让我们对所有项目进行概述，真是太棒了。我不知道如何在VSTS中做到这一点，而不深入到每个单独的项目中
  • 八达通在移动设备上可以很好地检查部署状态，甚至开始新的部署

• 社区

  • 八达通与客户合作，了解他们想要什么，他们经常发布RFC草案，并根据客户反馈多次完全改变路线

如果我们知道您正在部署什么样的应用程序，以及部署到什么样的环境中，我们将能够更好地调整我们的响应。

Answer 3

您今天在VSTS中看到的功能几年前还没有，所以可能有历史原因。但我想在这里说明一些非固执己见的原因，这些原因可能会建议一个组织选择不同的工具，而不是一个。

• 独立的责任和访问级别
• 开发团队中的多个CI工具(同时使用Jenkins或TeamCity或其他组织)，需要标准化和控制部署
• 组织需要一个只有八达通才能使用的功能(可能是多租户)

Answer 4

Octopus在专注于部署方面做得很好。功能在vsts之前到达章鱼，支持是本地的和响应性的。这样，您就永远不会用完构建/发布时间！

说真的，我只是想尽可能支持较小的公司，如果所有功能都相同，我仍然会选择它们。

Answer 5

过去的主要原因是TFS On prem和早期的VSTS根本不支持非Microsoft(.Net)代码。您可以利用TFS的源代码管理和工作特性，然后使用octopus/Jenkins等作为构建发布部分来覆盖TFS不知道该怎么做的代码。

此外，发布管道过去非常简单，在其他产品都是基于插件的情况下没有那么有用，并且可以(几乎)做任何你需要的事情。大部分情况都发生了变化，因此VSTS在使用非Microsoft代码库方面比过去好得多。随着时间的推移，整合会在公司内部产生，撤销这些决定可能比拥有"太多"工具更痛苦。此外，我觉得现在有更多的人熟悉这些工具，因为它们比VSTS成熟的时间更长，覆盖了开发世界的更大部分。

Answer 6

要完全实现CD，您需要两者。VSTS运行测试，是一个生成服务器。OD不是。VSTS轻于复杂的应用程序安装。如果您是IaC风格的资源调配环境，您还需要Terraform。不要试图把所有东西都硬塞进一个工具里。DevOps需要一个完整的生态系统。原因并非历史原因。