VSTS + Octopus部署？为什么我会看到很多CI/CD设置？

Question

我是一名过渡到Devops的开发人员.通过观察,我注意到很多开发商店已经开始使用Octopus Deploy和VSTS,或者他们正在开始设置devops ci/cd管道的新项目,他们规定使用这两种工具.

我已经对这两种工具进行了一些快速培训,虽然它们并不完全相同,但VSTS似乎提供了与Octopus Deploy相同的所有功能.

所以,我的问题是,如果一家公司已经在使用VSTS进行大部分版本控制,或者与CI/CD管道相关的任何内容,为什么要使用Octopus？它为您的构建和部署到VSTS使用Octopus提供了什么好处？

请注意,我对Devops非常非常新.我只是问,因为在"10,000英尺的视野",如果你已经在使用VSTS,那么Octopus似乎没有任何理由.我提到Octopus Deploy的名字,因为我看到它经常出现.但是,我假设可能有其他工具可以实现与VSTS集成的自动构建和部署相同的目的.但是,VSTS提供内置的构建和部署.为什么拆分工作？

Answer 1

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

• 相同的许可端到端
• 端到端构建和部署的视线

我之所以选择Octopus Deploy而不是VSTS Release，是因为：

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

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

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