文档首页 > > 理论实践> DevOps概览> DevOps VS 敏捷

DevOps VS 敏捷

分享
更新时间:2020/06/08 GMT+08:00

当我们面对敏捷和DevOps的时候,总会不可避免的思考下面这些问题:

  • 敏捷是什么?DevOps是什么?两者有什么区别?
  • 持续集成不是XP里面的么,怎么DevOps也有持续集成?
  • 我们团队之前在做敏捷转型,现在又开始DevOps转型,这两者有什么区别?

其实这些问题并没必要太过纠结,因为敏捷和DevOps两者都在不断演进,两者也的确越来越像。

这个话题注定讨论不清,也注定会有不同的意见。本文也仅从方法论和实践的角度,为开发者简单论述敏捷与DevOps。希望每位读者都会从本文中得到自己的理解与启发 ,帮助大家在敏捷与DevOps这两条路上走的更远。

  

先说本文的观点:

▪ 敏捷与DevOps初衷、目的是为了解决问题,而不是为了树碑立牌,更不是为了占领地盘。

▪ 两者并非泾渭分明,也没有一条线能够划出来,说哪边是敏捷,哪边是DevOps。

▪ 讨论敏捷与DevOps,目的是为了了解两者之间的内在联系,而不是为了划清界限。

▪ 经常被讨论的,是狭义的敏捷与DevOps概念,而广义的敏捷与DevOps,已经趋同。

▪ 两者都是试图去解决相同,或相近的问题,只是还没有能一招解决所有问题的办法出现。

  

接下来, 让我们从狭义的角度看二者的区别。

传统的敏捷是为了解决业务与开发之间的鸿沟。通过敏捷宣言中强调的个体和互动、可工作的软件、客户合作、响应变化,以及12条原则中的尽早的以及连续的高价值交付、自组织团队、小批量交付、团队节奏、可改善可持续的流程、保持沟通等,以及包括Scrum、Kanban、XP在内的众多管理和工程实践,来实现开发与业务之间的频繁沟通,快速响应变化。

而DevOps的出现,是为了解决开发与运维之间的鸿沟。前端的敏捷的确是快了,却发现因为Dev与Ops之间的隔阂,无法真正的将价值持续的交付给客户。

开发侧很快,运维侧太稳,这个就是我们常说的开发与运维之间固有的、根因的冲突,即下图中的混乱之墙。开发(尤其是“敏捷”后),求的是快速响应变化;运维,求的是稳定、安全和可靠的服务。更重要的,两者的KPI度量指标,绩效考核激励机制不同,决定了如果为达成各自的局部目标,势必存在无法调和的根因冲突。

DevOps的出现,就是为了打破开发与运维之间的部门墙,从这点上来说,“DevOps是敏捷在运维侧的延伸”这一说法也不无道理。只是,敏捷与DevOps,都已经不再是原来的那个敏捷和DevOps了;世界变化太快,问题域发生了变化,解决方案域自然也要随之变化。

敏捷的好处是,有一个敏捷宣言,宣告其诞生。敏捷的缺点,也许也是因为有敏捷宣言。敏捷宣言并不应该被拿来约束和限制敏捷的范围,敏捷宣言也说拥抱变化,宣言诞生于2001年,时至今日,也会与时俱进,只是后来再没有这样的一个标志性的事件来做声明。

DevOps的不好之处,是没有一个明确的定义。DevOps的好处,却也正是因为没有一个明确的定义做限制,所以拿来主义,一切好的东西,都可以为我所用。

DevOps是个筐,什么都可以往里装,敏捷又何尝不是呢?

通常人们对DevOps的理解有两方面,即D2O和E2E。D2O,Dev to Ops,即经典、狭义的DevOps概念,解决的是Dev到Ops的鸿沟。E2E,End to End,即端到端、广义的DevOps,是以精益和敏捷为核心的,解决从业务到开发到运维,进而到客户的完整闭环。DevOps的6C概念,即Continuous Planning、Continuous Integration、Continuous Testing、Continuous Deploy、Continuous Release、Continuous Feedback,也是端到端广义的DevOps。

维基百科中总结到,DevOps的出现,有四个关键驱动力:

  • 互联网冲击要求业务的敏捷
  • 虚拟化和云计算基础设施日益普遍
  • 数据中心自动化技术
  • 敏捷开发的普及

从种种概念可以看出,业务敏捷、开发敏捷、运维侧自动化、以及云计算等技术的普及,几乎打穿了从业务到开发到运维(包括测试),所以虽然字面上是Dev到Ops,事实上,已经是BizDevTestOpsSec了,即从狭义的D2O,前后延伸到E2E,端到端广义的DevOps了。

多位DevOps大师曾基于多年DevOps现状报告,汇聚出来了一个DevOps能力成长模型。在DevOps能力模型中,DevOps的最终的目的是组织效能,软件交付和运维效能是敏捷与DevOps共同的目标。

持续交付是狭义DevOps的核心理念,横跨了架构、开发、测试、运维等角色。持续交付的核心开发实践,也涵盖了架构管理、版本管理、分支策略、测试自动化、部署发布、运维监控、信息安全、团队授权、数据库管理等多个维度,其中不乏我们常说的传统的敏捷相关实践,尤其是下图中XP极限编程的很多实践,半数以上在DevOps里都能找到。

能力成长模型,除了持续交付,还包括精益领导力、精益产品开发、精益管理、组织文化与学习氛围。DevOps已远远不是CI/CD那么简单,CALMS原则也横跨了文化、管理、精益与技术。

敏捷宣言的十二条原则、SAFe的九大原则、以及DevOps的CALMS原则,也是彼此相互融合。SAFe有借鉴DevOps的理念和方法,DevOps又采纳敏捷的思想和实践,大家又都以精益为思想核心。那么谁包含谁,谁比谁大,彼此的界限在哪里呢?

由此可见,方法也好,实践也好,其价值应该由客户价值来体现。对客户而言,需要解决的问题,是端到端的,是全局而不是局部优化。

所以,是什么,不重要。能解决什么,要解决什么问题,很重要。

DevOps是集大成者,是各种好的原则和实践的融合,敏捷又何尝不是如此。2001年的17位雪鸟大师,各自在践行着不同的敏捷框架和实践。敏捷宣言和原则,原本就是一次融合。2003年Mary Poppendieck和Tom Poppendieck的精益软件开发方法,即便是已经有敏捷宣言的前提下,也一样纳入敏捷开发的范畴。敏捷也是在不断前行,DevOps与敏捷殊途同归,是同一问题的不同分支,最终汇集到同一个目标。

一个好的方法论,应该是与时俱进,兼容并蓄的;应该是开放的,演进的而不是固化的。

方法论如此,学习和实践方法论的人,更应该如此,以一颗开放的心态,接纳一切合理的存在。

  

最后,让我们来看看DevOps在工具链上的要求。DevOps要实现:自动化、标准化、配置化,就意味着一定要有能够实现端到端打通的自动化研发工具链。理论为我们指明实践的方向,而工具则是我们落地实践的基础。

华为云DevCloud提供软件开发全生命周期的云端DevOps工具链,帮助团队真正实现自动化、标准化、配置化。

DevCloud提供基于Git的版本控制系统,不只将代码版本化,而是版本化管理一切与环境有关的配置。

可自定义的自动化部署流水线,提交代码自动触发,帮助团队实现持续交付,为团队带来自动化、标准化。

  

本文参考资料

  • 《DevOps explained》 Jérôme Kehrli
  • 《Accelerate》

  

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!

非常感谢您的反馈,我们会继续努力做到更好!

反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

智能客服提问云社区提问