VSTS +章鱼部署？为什么我同时看到很多CI / CD设置？

Question

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

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

所以，我的问题是，如果公司已经在使用VSTS进行大部分版本控制，或者与CI / CD管线相关的任何事物，为什么要使用Octopus？使用章鱼构建并部署到VSTS有什么好处？

注意，我对Devops非常陌生。我只是问，因为在“ 10,000英尺视角”下，如果您已经在使用VSTS，似乎没有任何理由使用八达通。我之所以提到Octopus Deploy是因为它经常出现。但是，我认为可能还有其他工具可以实现与VSTS集成的自动构建和部署的相同目的。但是，VSTS提供了内置的构建和部署。为什么要分开工作？

Answer 1

让我开始为什么我喜欢同时使用VSTS进行构建和部署：

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

与VSTS版本相比，我更喜欢Octopus Deploy：

• 能够上传软件包/工件
  • 可能是一个软件包的外部软件包，可以针对特定版本进行部署
• 目标定义
  • 在创建要部署到的目标或服务器时，您可以将目标添加到一个或多个环境中，并为目标分配标签/角色。这是什么意思？可以使用更灵活的服务器定义，而不是将严格的代理定义为池或将服务器定义为部署组，而可以允许目标跨越多个对象（即：跨越您的Dev和Test环境并且仅在针对以下条件定义的步骤上触发的测试服务器）该角色）。我意识到您可以在VSTS中完成与此类似的操作，但我认为这要麻烦得多。
• 变量定义
  • 可以在全局级别对变量进行分组，并可以通过特定的管道/流程（该部分类似于VSTS）对变量进行分组。变量也可以按环境或角色进行分组或scoped（如上所述），因此您可以为每个环境的每个角色使用不同的变量值。既超级颗粒又灵活。如果您有一个带有连接字符串的后端服务器，并且也许有2个内容传递节点（角色-{content delivery），它们的值与后端服务器的不同略有不同，则此方法很方便。目前，我不知道（除了创建新的环境），如何在VSTS中实现相同的目标。
• 流程定义
  • 以上所有内容都包含在Octopus Deploy的流程定义中。超级灵活，精细的变量和目标定义使您可以专注于 actual 部署过程，而不必迷恋UI的细微差别及其限制。一个示例是定义一个过程，第一步是从中央服务器从负载均衡器中取出某些东西，第二步将代码部署到交付服务器一中，第三步放回lb中，第4步从lb中取出节点二，称为从中央服务器开始，第5步将代码部署到第二个节点，最后一步，将其部署到负载均衡器中。我意识到这是一个非常简单的假设，但是在Octopus Deploy中，这是一个经过过滤的稳定过程，可以在特定角色上执行，而在VSTS中，您必须将其分解为不同的代理阶段，甚至可能分为管道。

以上是我在VSTS Release上使用Octopus Deploy的最大重点。现在为什么有人要使用VSTS进行构建并使用OD进行发布/部署？涉及到许多不同的因素，其中一些是企业驱动程序，例如拥有通过MSDN处理权限的企业git客户端。有时，这是项目管理的驱动力，它使工作项紧密地联系在一起以进行提交和构建，但是OD带来了额外的灵活性，从而使免费/最低成本成为可能。

希望这可以帮助我们了解为什么有些人越过溪流并同时使用VSTS和OD。

Answer 2

已经提出了很多优点，但这确实取决于您的需求。我敢冒险，在发行管理真正成为现实之前，我们中的很多人开始使用章鱼。

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

当我们开始评估工具时，VSTS不能用于部署。即使是现在，他们仍在功能上赶上章鱼。

如果您要进行真正的多租户和多环境部署，那么我认为VSTS不能与之相比。我们使用的Octopus大约有30位租户，有些在Azure上，有些在内部。我们部署了Web和桌面应用程序。我们甚至使用Octopus来部署一些旧版VB6和Winforms应用程序。

• 多租户（对我们很重要）

  • VSTS不久前添加了部署组，这听起来与实施多租户之前的Octopus环境非常相似。在Octopus实现真正的多租户服务之前（现在已经有一段时间了），人们可以通过为每个租户创建不同的环境来解决它，例如“ CustomerA-Dev”，“ CustomerA-Prod”等。现在，您只需拥有自己的Dev /测试/生产环境和每个租户可以将变量的作用域限定为那些单独的环境。

• 支持

  • 文档非常好，并且非常容易启动和运行。
  • 我几次需要与Octopus的人联系时，他们的回答非常迅速且知识渊博。

• 可用性

  • 拥有Octopus仪表板，使我们可以概览所有项目，这真是令人惊讶。我不知道要在VSTS中执行此操作，而不涉及每个单独的项目。
  • Octopus在移动设备上可以很好地用于检查部署状态，甚至可以启动新的部署。

• 社区

  • 章鱼与客户合作以了解他们的需求，他们经常发布RFC草案，并根据客户反馈多次改变路线。

如果我们知道您要部署哪种类型的应用程序以及在哪种环境下，我们将能够更好地调整响应。

Answer 3

您在VSTS中今天看到的功能是几年前不存在的，因此可能有历史原因。 但我想在此说明一些不受质疑的原因，这些可能建议组织选择不同的工具，而不是一个。

• 单独的责任和访问级别
• 开发团队（也使用Jenkins或TeamCity的组织）中的多个CI工具，需要标准化和控制部署
• 组织需要仅在章鱼中可用的功能（也许是多租户）

Answer 4

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

尽管如此，我很想尽可能地支持较小的公司，如果所有功能都相同，我仍然会选择它们。

Answer 5

过去的主要原因是TFS on prem和早期的VSTS根本不很好地支持非Microsoft（.Net）代码。您可以利用TFS的源代码控制和工作功能，然后使用octopus / Jenkins等...作为构建发行版的一部分，介绍TFS并不真正知道该怎么做的代码。

在其他产品都基于插件并且可以（几乎）完成您需要的所有功能的情况下，发布管道过去也非常简单，没有太大用处。其中大多数已更改，因此VSTS在处理非Microsoft代码库方面比以前要好得多。随着时间的流逝，要在公司内部建立集成，而仅仅拥有“太多”的工具，撤销这些决定可能会更加痛苦。我还感觉到有更多的人熟悉这些工具，因为它们已经比VSTS拥有更长的成熟时间，并覆盖了VSTS过去的大部分开发领域。

Answer 6

要完全实现CD，您需要两者。 VSTS运行测试，并且是构建服务器。 OD不是。 VSTS很少使用复杂的应用程序安装。而且，如果您要配置IaC风格的环境，则还需要Terraform。不要试图将所有内容整合到一个工具中。 DevOps需要整个生态系统。原因不是历史原因。