欢迎您光临本站,如有问题请及时联系我们。

一张图带你了解“持续交付”和“DevOps”的前世今生

  1. 敏捷软件开发方法从来就没有一种方法,叫做“敏捷软件开发方法”。因为,IT行业中的“敏捷(Agile)”一词,从2001年它的诞生之日起,就是个软件开发方法集合,当时这个集合中的方法,都遵从敏捷宣言和相同的工作原则(十二原则),它的缔造者是十七位软件工程师(请查敏捷,雪鸟会议)。目前,在这面大旗下,又增加了很多种方法,当然也有很多方法走出了人们的视线。

  在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调“敏捷宣言”和“十二原则”了,只在培训课堂上还能听到。

  2. 持续集成早在1999年KentBack的《解析极限编程》一书中,对“持续集成”这一概念就有提及,它是极限编程XP方法中的十二最佳实践之一。在2004年,Martin Fowler发表的一篇博文上,给“持续集成”下了一个定义,并一直沿用至今。即:“持续集成是一个软件开发实践, 是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次, 这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题。” 这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了。 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫“极限”二字了。

  3. DevOps在2008年的一次敏捷大会上,运维相关人员就“敏捷基础设施(Agile Infrastructure)”展开讨论,并在2009年以后逐步发展成为一场大规模“运动”,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让DevOps多了一些发力点。

  4. 持续交付Jez Humble和David Farley在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。

  它们的关系1. 空间与时间维度根据以上的信息,我认为它们在空间和时间维度的关系是这样的:

持续交付与DevOps

  上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?

  2. 人或组织维度我的微信签名是“别提概念,只解决问题!”。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里:“所有的问题,都是人的问题”。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?

持续交付与DevOps

  持续集成,有助于打破开发人员和测试人员之间的“墙”。

  敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的“墙”。

  DevOps,有助于打破开发团队与运维团队之间的“墙”。

  持续交付,则是希望从端到端的角度,考虑如何解决问题。

  为什么从“人”开始在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与“人”相比,技术实践并不需要太在意,即:最好还是先从“人”的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。

  从哪里找问题从参与者的问题陈述中找问题。比如:

  老板:

  “项目经常延期” “做东西太慢”

  产品:

  “老板的想法总变”

  “事情太多,忙成狗”

  “开发说这个实现不了”

  开发:

  “需求总变”

  “UI方案给的太晚”

  “活儿太多”

  测试:

  “需求变了没提前通知”

  “测试时间总被压缩,还要背锅”

  “重复测试太多遍”

  运维:

  “每天这么多版本上线,活干不完,出事儿第一个背锅。”

  每句话的背后都有很多含义。开挖吧~~

  提问题的人是问题的创造者,也是接盘侠~

  从哪里找解决方案在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:

  构建管理和持续集成

  环境与部署

  发布管理和和符合性

  测试

  数据管理

  配置管理

  通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:

持续交付与DevOps

  我也没有称其为成熟度模型,而是“持续交付七巧板”。

  是的,中国的传统玩具“七巧板”,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。

  找正确的问题去解决上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:

  怎么做持续交付?

  怎么做持续集成?

  怎么做敏捷?

  怎么做DevOps?

  我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种“捷径”。

  我们做的是敏捷吗?

  我们这么做持续交付,对吗?

  我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?

  你这不是敏捷?

  你这不是DevOps?

  你这不是持续交付?

  你这不是持续集成?

  我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~

  再炒一炒冷饭2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:

  1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?

  正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。

  2. 标题党啊

  好吧,我承认在那个很少有人提及“DevOps”的年代,我就做标题党吧。

  这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。

  一、了解环境背景当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。

  几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念)。一个从Google跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难。 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队。

  团队间接管理者

  项目交付不太可控:

  我们一直在做计划,但计划性非常差。

  经常有各种各样的情况发生,总会让项目改期。

  团队直接管理者

  我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。

  这个项目中,有一部份需求必须在XXX时间点完成。

  团队Lead

  估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。

  我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。

  开发人员

  领导说试一下,就试一下吧。

  测试人员

  工作经常被打断。

  提测质量不高,经常浪费精力。

  出了Bug,影响太大。

  (这里省略一千字)。

  二、找到正确的问题来解决(目标)三个月内:

  (1)该项目交付时间可预期。

  (2)建立新的软件开发协作方式。

  (3)建立必要的基础设施,以支持后续的持续发布模式。

  三个月后:

  (1)需求的周期时间缩短,可以短周期上线。

  (2)生产环境的质量不降低。

  (3)测试人力总投入降低。

  在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)

  通常行为的改变,需要一个半月的时间;

  带来强烈可感知的收益需要三个月的时间。

  三、承诺是必须的上面的问题(目标)找到了,也要一并承诺。

  要想让团队和你走,你必须站在前面。

  四、培训及过程指导需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。

  启蒙培训(1小时)

  对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。

  重新定义工作流程

  新的项目工作流程

  新的迭代工作流程

  新的需求工作流程

持续交付与DevOps

  新的代码工作流程

持续交付与DevOps

  解决新流程中的障碍

  团队沟通和协作的方式。

  编译环境的准备。

  编译时间的缩短。

  自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。

测试金字塔

  自动化测试运行的环境的准备。

  自动化测试编写时机与自动化的利用。

  自动化测试用例代码管理。

  我和运维人员的对话(真实的场景再现)

  我:我们团队想每两周就部署一次服务 运维:不行 我:为啥? 运维:线上需要稳定 我:每两周部署一次,就不稳定了吗? 运维:原来的质量太差,每次上线总是出问题 我:现在质量很好 运维:怎么可能? 我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足; 运维:那也不行 我:为啥 运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?

  怎么解决?

  改变部署方式,让他的工作生活美好起来吧~~~~~

持续交付与DevOps

  部署流水线的建立,要求一键部署

  运维人员负责编写部署脚本,并做版本管理。

  开发人员在开发自测时使用同样的脚本。

  测试人员在测试环境上使用同样的脚本。

  运维人员在生产环境上也使用同样的脚本。


来源:本文由E8运维原创撰写,欢迎分享本文,转载请保留出处和链接!