一张图带你了解“持续交付”和“DevOps”的前世今生
《一张图带你了解“持续交付”和“DevOps”的前世今生》要点:
OK,就这四个啦: “敏捷软件开发”,“持续集成”,“DevOps”,“持续交付”, 先让我们在Wikipedia上验明正身. 在Wikipedia上的定义敏捷软件开发
持续集成
持续交付
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. 空间与时间维度根据以上的信息,我认为它们在空间和时间维度的关系是这样的: 上面这个图是从实践或环境的角度来看它们之间的关系.那么,如果我们换一个角度呢? 2. 人或组织维度我的微信签名是“别提概念,只解决问题!”.所以我更愿意从解决问题的角度看这些概念.一谈到问题,就有一个经典的话浮现在我脑海里:“所有的问题,都是人的问题”.所以,这个角度看到的才是本质.那么,它们的关系是什么呢? 持续集成,有助于打破开发人员和测试人员之间的“墙”. 敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的“墙”. DevOps,有助于打破开发团队与运维团队之间的“墙”. 持续交付,则是希望从端到端的角度,考虑如何解决问题. 为什么从“人”开始在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与“人”相比,技术实践并不需要太在意,即:最好还是先从“人”的角度看问题.真正去解决问题时,上面说的种种概念并不是那么重要.它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践).而且,在解决问题时,你也不必整套选择这些工具. 从哪里找问题从参与者的问题陈述中找问题.比如:
每句话的背后都有很多含义.开挖吧~~
从哪里找解决方案在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”.在这个模型中,包含如下六个维度:
通过实际工作的验证,我发现,这里面缺失了一些东西.所以,增加了一些维度,并重组了一下,如下图所示:
找正确的问题去解决上面的诸多概念并不是你的问题或目标,而只是你的工具(手段).千万不要把手段当成你的目标来实现.很多人问:
我猜测你是想问:是否有捷径做XXX.当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种“捷径”.
我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?
我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题.我们还是先讨论清楚问题吧~ 再炒一炒冷饭2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:
这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要. 一、了解环境背景当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围. 几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念).一个从Google跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难. 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队. 团队间接管理者
团队直接管理者
团队Lead
开发人员
测试人员
二、找到正确的问题来解决(目标)三个月内: (1)该项目交付时间可预期. (2)建立新的软件开发协作方式. (3)建立必要的基础设施,以支持后续的持续发布模式. 三个月后: (1)需求的周期时间缩短,可以短周期上线. (2)生产环境的质量不降低. (3)测试人力总投入降低.
三、承诺是必须的上面的问题(目标)找到了,也要一并承诺.
四、培训及过程指导需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认. 启蒙培训(1小时) 对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙. 重新定义工作流程
解决新流程中的障碍
我和运维人员的对话(真实的场景再现)
怎么解决? 改变部署方式,让他的工作生活美好起来吧~~~~~
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |