代码之家 › 专栏 › 技术社区 › RLH

VSTS+章鱼部署为什么我会看到很多CI/CD设置都有?

octopus-deploy azure-devops

RLH · 技术社区 · 8 年前

我是一个向Devops过渡的开发人员通过观察,我注意到许多开发人员已经开始使用octopus deploy和vst,或者他们正在启动新的项目来设置devops ci/cd管道,并且他们指定使用这两种工具。

我已经对这两个工具进行了一些快速培训,虽然它们并不完全相同,但vsts似乎提供了与octopus deploy相同的所有功能。

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

注意,我对Devops非常非常陌生我只是问,因为在“10000英尺视图”似乎没有任何理由章鱼,如果你已经使用VST我提到章鱼部署的名字,因为我看到它经常出现不过,我认为可能还有其他工具可以实现自动构建和部署的相同目的,这些工具也可以与vst集成。然而,vsts提供了一个内置的构建和部署。为什么要分开工作?

6 回复 | 直到 8 年前

David Gardiner 8 年前

让我先解释一下为什么我喜欢使用vst构建和部署:

同样的许可
从端到端构建和部署的视线

我喜欢Octopus Deploy胜过VSTS Release的原因:

能够上传包/工件
- 外部的,可能是为特定版本部署的一次性包
目标定义
- 创建要部署到的目标或服务器时,可以将目标添加到一个或多个环境中,并为目标分配标记/角色。这是什么意思?更灵活的服务器定义,而不是将严格的代理定义为池或服务器到部署组,可以允许目标跨越多个(即:跨越您的DEV和测试环境的测试服务器,并且仅在为该角色定义的步骤上触发)。我知道你能做到 类似的 但在我看来这要麻烦得多。
变量定义
- 变量可以在全局级别分组,也可以按特定的管道/进程分组(该部分类似于vst)变量也可以分组或 scoped 通过环境或角色(以上),因此每个环境的每个角色都可以有不同的变量值;既有超粒度又有柔性。如果您有一个带有连接字符串的后端服务器,并且可能有两个内容传递节点(角色- content delivery )有点 不同的 值大于后端服务器目前,我不知道(除了创建新环境)如何在vsts中实现相同的功能。
过程定义
- 以上所有内容都集中在octopus deploy的流程定义中。超级灵活的粒度变量和目标定义使您可以专注于 实际的 而不是被用户界面的细微差别及其局限性所困扰一个例子是定义一个过程,其中第一步是从中央服务器的负载平衡器中取出一些东西,第二步是将代码部署到传送服务器1,第三步是将代码放回lb,第四步是将节点2从中央服务器调用的lb中取出,第五步是将代码部署到节点2,最后一步是将代码放回负载平衡器我知道这是一个非常简单的假设,但是在Octopus Deploy中,它是一个稳定的过程,经过过滤后可以在特定的角色上执行,在VSTS中,您必须将其分解为不同的代理阶段,可能还有管道。

以上是我看到的使用octopusdeployovervsts发布的最大要点现在为什么有人要使用vst来构建和OD来发布/部署呢其中有很多不同的因素,有些是公司驱动程序,比如有一个通过msdn处理权限的企业git客户端。有时,它是一个项目管理驱动程序,它将工作项紧密地绑定到提交和构建,但是具有OD带来的自由和最小成本的附加灵活性。

希望这有助于揭示为什么有些人会穿越河流,同时使用vst和od。

Mark 8 年前

已经提出了很多好的观点,但这真的取决于你需要什么。我敢说我们中的很多人在发布管理真正成为一件事之前就开始使用章鱼了。

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

当我们开始评估工具时,vst没有任何可用于部署的东西。即使是现在,他们仍然在功能集中玩追赶章鱼的游戏。

如果您正在进行真正的多租户和多环境部署,我认为vsts没有真正的可比性。我们正在使用八达通,大约有30个租户,有些在Azure上,有些在premise上我们部署了web和桌面应用程序的混合。我们甚至使用octopus来部署一些传统的vb6和winforms应用程序。

多租户 (对我们至关重要)
- VSTS不久前添加了部署组,这听起来非常类似于实现多租户之前的Octopus环境在Octopus拥有真正的多租户之前(现在已经有一段时间了),人们会通过为每个租户创建不同的环境来解决这个问题,比如“CustomerA-Dev”、“CustomerA-Prod”等等。现在您只需要创建Dev/Test/Prod环境,每个租户都可以将变量范围设置为这些单独的环境。
支持
- 文档非常好,而且很容易安装和运行。
- 有几次我需要和章鱼公司的人联系,他们的回答很快,很有见地。
可用性
- 有章鱼仪表盘给我们的所有项目的概述是惊人的我不知道在VSTS中做这个,不去每个项目。
- Octopus在移动设备上非常适合检查部署状态,甚至可以启动新的部署。
社区
- 八达通与客户合作,了解他们想要什么,他们经常发布草案的RFC,并有几次完全改变的过程,根据客户的反馈。

如果我们知道您正在部署什么类型的应用程序,以及部署到什么类型的环境,我们将能够更好地定制响应。

Giulio Vian 8 年前

您今天在vsts中看到的功能在几年前就不存在了,所以可能有一个历史原因。但我想在这里陈述一些非固执己见的理由,这些理由可能建议一个组织选择不同的工具,而不是一个。

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

Ben Cull 8 年前

章鱼在部署方面做得很好特性在vsts之前到达octopus,支持是本地的和响应的这样,您就永远不会耗尽构建/发布时间!

不过,说真的,我只是喜欢尽可能支持小公司,如果所有功能都一样,我还是会选择它们。

Paul Swetz 8 年前

过去的主要原因是prem和早期vst上的TFS根本不支持非Microsoft(.Net)代码你可以利用TFS的源代码管理和工作特性,然后使用octopus/Jenkins等作为构建版本的一部分来覆盖tfs不知道该如何处理的代码。

另外,发布管道过去非常简单,在其他产品都是基于插件的并且可以做(几乎)任何你需要做的事情的地方没有那么有用。大多数情况都发生了变化,因此VSTS在使用非微软代码库方面比以前要好得多随着时间的推移,在公司内部形成了集成,撤销这些决定可能比拥有“太多”工具更痛苦另外,我觉得有更多的人熟悉这些工具,因为它们已经成熟得更久,覆盖了开发世界的更大一部分,而vsts在过去已经如此。

Jeffrey Palermo 8 年前

要完全实现cd,您需要两者。vsts运行测试并且是一个生成服务器。OD isn t.VSTS对于复杂的应用程序安装来说是轻量级的如果你是配置环境,IaC风格,你还需要Terraform不要试图把所有东西都塞进一个工具中。DevOps需要一个完整的生态系统。原因不是历史的。