软件交付过程是指在编程序改代码之后,直到将软件发布给用户使用之前的一系列活动,如提交、集成、构建、部署、测试等。本书作为通识类图书,对软件交付过程的各个方面进行了全面综合的介绍。这包括三部分内容:第1部分,介绍在研究软件交付过程时常见的思路和思考框架;第2部分,梳理软件交付的总体过程;第3部分,考查软件交付过程中的各个具体活动。总的来说,本书提供了一种类似于对人进行体检的方法,对特定软件产品的交付过程进行全方位的调研,可以根据其所在的业务领域、当前采用的技术栈、使用的工具、流程和方法等实际情况,找出当前最突出、最值得改进的问题。
媲美大师经典彻底讲透软件交付||数字化转型、DevOps、持续集成、持续交付、持续部署、敏捷万用宝典
推荐序
近年来关于DevOps的讨论和实践,可谓是“风起云涌”,作为一项新型的理念和技术的综合体,其出现时间也就十来年,关于它的定义,难免仁者见仁,智者见智,现在我们摘取维基百科上的相关表述如下。考虑到中文版和英文版有些差异,因此一并列出。
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.
DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
两个语言版本的维基百科,有些不同之处。英文版提及了“持续交付”,中文版提及了“软件交付”,本书作者可能基于深度思考,也可能简单觉得“持续交付”被提及太多已然不酷(流水先生,即本书作者董越老师,不要生气哟),于是采纳“软件交付”作为本书书名的关键词。当然,不管称呼为“软件交付”还是“持续交付”,都可被认定是DevOps的核心工程实践。
DevOps的三个问题
DevOps火热得快,关于它有多个“未解之谜”,向来众说纷纭,这里暂且列举3个和你进行探讨。
首先,DevOps的两个CD究竟是什么关系?
有两个与DevOps相关的重要概念:持续交付(Continuous Delivery)和持续部署(Continuous Deployment),其简称都是CD。那么,这两者之间究竟是什么关系呢?
有人说,持续交付和持续部署是包含关系,前者包含后者。部署就是把程序包放到服务器上,无论把程序包放到测试服务器上还是生产服务器上,都被称为部署。所以,从字面上理解持续部署这个概念的话,持续交付理应包含持续部署,在之前包含持续集成,在之后包含持续发布。这听起来好像很有道理。
也有人说,持续交付和持续部署是递进关系,后者是前者的递进。这种关于持续交付和持续部署的分界定位的说法认为,持续部署所说的“部署”,是指生产环境部署,让生产环境的部署比持续交付时更频繁。追根溯源,其实这个说法才是当初提出“持续部署”这个概念的本意。Martin Fowler在他的博文中也写到,“持续部署意味着每个通过部署流水线的变更都被自动地部署到生产环境中,于是每天都会有若干次生产环境部署。”Jez Humble在《持续交付:发布可靠软件的系统方法》这本书中有更详细的介绍。维基百科也给出了类似的定义。本书作者也是按照这个定义来介绍的。
大家在阅读各种文章、各种图书时,看到“持续部署”这个词,心里可得有根弦儿——这里说的“持续部署”到底是什么含义。最好是文中就给出了它的定义。
类似的情况还有“特性团队”这个概念,特性团队中的“特性”其实和特性分支中的“特性”是完全不同的含义。本书中对特性团队、特性分支的概念也都做了明确的辨识和讲解。事实上,本书对DevOps、软件交付领域的众多重要概念都给出了明确的定义。
其次,DevOps只是昙花一现吗?
关于DevOps,其生命周期也是众说纷纭。“看衰者”说,DevOps也就昙花一现,可能速速消失在软件世界的“历史”长河中;“看好者”说,DevOps是软件工程领域的第三次革命,路还长着呢。那么,谁对谁错呢?
DevOps运动,强调从组织、流程规范特别是技术上把运维甚至安全(DevSecOps)等纳入进来,打通“最后一公里”,实现真正的端到端,从需求端到最终用户端。
然而,要想让一个团队做好这些,那就需要这个团队很强。但这很难,怎么办?可以让事情变得容易做,用不着那么专业的人来做。所以要开发各种工具,实现各种自动化,让工具足够好用,以至于一个人或者一个团队就可以做好集成发布过程,做好应用的运维、监控等各种操作。
具体而言,基于DevOps最佳实践,充分运用自动化技术形成了虚拟的、可被大量复制的软件生产及发布流水线。新功能开发完成后,不再需要请运维人员部署到测试环境,不再需要请测试人员做测试,开发人员可以一键触发自动化部署、自动化测试。
这样一来,通过DevOps的理念及技术指引,就真正实现了减少协作。
所以看来,DevOps的核心——持续交付,侧重于工程技术及落地实践,其打通了面向终端用户(价值)的“最后一公里”,看来不是昙花一现。
这跟本文作者前段时间的一个精彩发现不谋而合:高效协作的核心秘密是减少协作。
为什么这么说?因为人和人之间的合作是很累的,身体累,心更累。沟通需要不少时间,以理解上下文、进入状态(被打断后又得重新进入状态)。协调也需要不少时间,各有优先级,有各种争抢、各种排队、各种等待。若是赶上年假、时间冲突、新冠肺炎疫情等,那更麻烦。还有说不清道不明的人际关系及“软拒绝”。所以说,尽量一件事情能够从头到尾独立完成。
尽可能让一个人或者一个团队能够把一件事情负责到底。说到开发软件,就是从需求一直到上线。如果一个人做不好,那就一个团队来做,即所谓的全流程团队(或者全功能团队、跨职能团队、特性团队、stream-aligned team等),这个团队有着共同的目标,那就是已发布,而不是已开发、已测试或者已部署。这很类似于特种部队,其往往融合了海陆空的各种技能于一体,像一把尖刀,指哪打哪。
这不就是DevOps嘛!高效沟通的关键所在就是减少沟通,DevOps使得这些构想从理想变为现实。
最后,DevOps可以有标准吗?
正如维基百科所言,DevOps首先是一组最佳实践。DevOps融合了“务虚”和“务实”,既包括组织、流程、文档乃至文化,也包括自动化构建、自动化测试、自动化部署及发布等工程技术,法无定法,那么,DevOps会有标准呢?
DevOps就像水一样,水并无常态,有时液态,有时固态,有时气态,然而,喝水是否需要容器呢?小孩喝水用奶瓶,青年人喝水用塑料瓶,中年人喝水用保温杯。同理,DevOps作为最佳实践,其在各行业应用时,作为工程技术,还是有章可循的。例如,银行、证券和保险等行业,开展的业务是类似的,业务形态是相近的,部分业务系统甚至都外采于同一个供应商。
而且,这些都是从计算机软件生长出来的,在DevOps之前,也是多采用瀑布式开发模式,那么随着时代的车轮滚滚向前(云计算及云原生方兴未艾),DevOps必然也是大势所趋。
另外,我们所讨论的标准,并非平面标准(0或者1,通过或者不通过),而是能力成熟度模型,分为5级,主要以技术规范为主,颇具指导意义。
据说,现在各大国有银行、全国性股份制银行、城商行、头部券商及头部保险公司、运营商头部省公司等,都已纷纷前后“贯标”,相关项目的软件质量提升60%以上,需求发布速度提高300%以上。
软件交付的核心策略及金句
流水先生在互联网行业有很多年的DevOps实践,近两年因为机缘巧合,和众多金融名企如大中型银行及运营商等有过较长时间的深度接触,因此形成了十大核心策略。在关于十大核心策略及其在软件交付过程中如何应用的描述中,金句不断,在此采撷一二,以飨读者。
? 细粒度、低耦合,自己完成一件事情,不要总是动辄牵扯到别的人、别的事,这是软件交付的第一个策略。
? 在各个方面追求小批量:小批量的设计功能、交代开发任务,小批量的集成,小批量的测试,小批量的发布。于是,就有可能让整个流程持续地流动起来,而不是走走停停。
? 自动化工具要好用。其中比较重要的一点是,用户可以方便地自行配置使用,也就是自助化。
? 适当交叠有益,过分交叠有害。
? 每次代码改动提交,都应该是逻辑上完整地完成了一小块改动。
? 经典的持续集成方式是:开发人员可以随时向集成分支提交代码改动,而每次提交代码改动时都会触发一系列轻量级的自动化测试。
? 作为一个硬指标,通常应该是每次代码改动提交本身就既包括源代码的编写和改动,也包括相应单元测试脚本的编写和改动,并且这段单元测试脚本已经运行通过。
一个有趣的人和一本引人入胜的书
这是一本“老顽童”写的、看着不累的、“老少皆宜”的书。
“老顽童”加上双引号,主要不是因为流水先生“不顽皮”,而是因为不够老,毕竟流水先生正处于羽扇纶巾、大有可为的尚好年华。
流水先生治学严谨,相关著作侧重逻辑性,严格按照《金字塔原理》一书推荐的结构,层层递进,抽丝剥茧式向读者一一呈现;同时流水先生注重行文的诙谐幽默,尽量用通俗的语言娓娓道来,就像一位和蔼可亲的邻家大哥哥,“温柔地”注视着你,说,故事是这样的……
本书逻辑严谨,又不失轻松幽默。在提及本书的目的是“提供一种系统全面的方法”时,流水先生写道,“梳理出它在软件开发过程方面应该做哪些改进,以及轻重缓急,然后再从你的工具箱里拿出匹配的合适的工具,叮叮当当。”
“如果不是因为好玩儿,人生该多无趣啊!”流水先生是这样说的,也是这样身体力行的。
流水先生喜爱苏州评弹,这些年经常光顾同一个评弹小馆,去了多少次,我估计平江街的每一块铺路石单单根据受力情况,就知道。“哟,流水先生您又来了!”“对,去这儿。”“您里边请。”我甚至愿意相信,流水先生在编写本书时,脑海里就是以苏州评弹作为背景音乐的。
当年孔子向师襄学琴,师襄教了他一首琴曲,让他回去练习。他一弹就是十天。师襄觉得孔子已然弹得甚好,反复请孔子去学习其他新曲儿,但孔子总觉得不到位,即使他已经领会了琴曲的内涵。直到孔子说自己体会出作者是一个怎样的人了,他肤色黝黑,身材高大,目光明亮而深邃,似是一个统治四方诸侯的王者。师襄听后甚为惊叹,说:“这就是《文王操》啊!”
如果读者在赏阅本书的过程中,能咂摸出流水先生在写书时的音容相貌、神态表情,那就真的厉害了。前三位如实描绘出来的读者,请找流水先生或者我领取奖励一份。
——萧田国 高效运维社区发起人、DAOPS基金会中国区执行董事
评审与致谢
本书经过了14位评审人认真细致的技术评审。没错,是认真细致、逐字逐句的技术评审,共收到788条评审意见,其中大部分被采纳。本书写作用了两个多月的时间,而根据评审意见修改又用了两个多月的时间。所以,这本书其实不是作者一个人完成的,而是作者和各位评审人共同完成的。
本书的评审人包括:企业中一线开发团队的负责人;企业中软件开发工具与流程改进的负责人;精益敏捷、持续交付、架构、测试、运维等方面的业界专家;DevOps标准(指中国信息通信研究院的研发运营一体化(DevOps)能力成熟度模型)的持续交付部分核心编写者。下面分别介绍(按拼音排序)。
陈展文,在招行服务18年,伴随着招行信息技术部从200多人发展到现在5000多人的规模,获得了PMP、CSM、CSPO、CSP、DOF、DOP、AWS CSAA认证。从推动配置管理工具Firefly起步,全程参与CMMI 三级体系的建立和认证,牵头招行CC、CQ、BuildForge、RTC和Git等全平台配置管理工具的落地实施。2015年开始牵头研究和推进DevOps持续交付实践落地,更好地支撑招行的精益化转型。2018—2019年牵头招行25个项目参与“DevOps标准持续交付部分3级评估”。2018年 DevOps国际峰会深圳站、2019年GOPS深圳站、2019年DevOps国际峰会北京站、2020年GOPS深圳站金牌讲师。担任QECon2020上海站与2021深圳站精益和敏捷专场出品人。
丁晓娇,百度DevOps方案架构师/资深敏捷教练,专注软件过程改进工作13年,4年研发管理经验;精通企业精益敏捷/DevOps转型方法和实践。具备互联网、金融、通信、电气等行业大中型企业DevOps或敏捷转型方案和落地经验。
段新,目前就职于中国移动广东公司,曾长期专注企业架构规划和转型实施。近年来痴迷于研究精益敏捷、DevOps在软件交付中的引入和推广,发现企业架构、精益敏捷、DevOps在软件质量与效能目标上的高度统一和互通,顿觉豁然开朗。
郭宏泽,15年IT行业工作经验,曾就职于易车网、电信云计算、跟谁学等公司。企业IT架构咨询师、IT培训师,曾为国内外各大公司做过专职咨询与培训。现任职于华图教育集团,担任技术总监。开发过日志分析系统、CDN流量计费结算系统,自动化IT管理平台、AdminSet开源运维管理平台作者。
华飞,就职于中原银行工程效能团队,主要负责企业内部DevOps平台建设。
井博巍,大家养老保险自营销售平台研发经理,乐于探索DevOps模式与敏捷思想,结合实际项目持续实践,提升项目效能并推广实践经验。深耕保险行业,关注IT项目在业务、技术、管理上的结合方案。曾任职于泰康养老,带领试点项目团队,实现DevOps模式转型。
景韵,DAOPS 基金会首席布道师,DevOps标准核心编写专家,DevOps Enterprise Coach,先后就职于用友、乐视,从事持续交付、DevOps 落地改进工作。
雷涛,Jenkins全球推广大使, DevOps标准工作组核心编写专家, DevOps Enterprise Coach,曾就职于百度、爱立信、摩托罗拉、诺基亚、新浪网等国内外知名企业,专注于互联网、金融、电信、汽车等行业的软件研发交付效能提升,包括企业级DevOps解决方案、持续交付、ASPICE/ISO 26262研发过程落地等领域。
李青,华泰证券股份有限公司效能专家,曾就职于摩托罗拉和中国移动。在15年的职业生涯中,从事过软件开发、项目管理、敏捷导入和产品设计等多种软件研发相关工作,跨越移动终端、运营商、互联网和游戏等多个领域,深入了解了不同角色、不同行业的研发过程。加入华泰证券以来,致力于推广精益理念,拥抱DevOps转型。作为项目经理和产品经理,主持打造了华泰证券的首个DevOps平台,并持续向研发过程一体化平台演进。
刘婷,郑州银行信息科技部基础平台科主管,主要负责持续交付平台等研发管理平台的建设;曾就职于百度质量部,负责运维软件及服务器硬件的测试开发工作。
牛晓玲,中国信息通信研究院云计算与大数据研究所治理与审计部副主任、DevOps系列标准及国际标准编写人。长期从事开发运维方面的相关研究工作,包括云服务的运维管理系统审查等相关工作。参与编写“云计算服务协议参考框架”“对象存储”“云数据库”“研发运营一体化(DevOps)能力成熟度模型”系列标准,以及“云计算运维智能化通用评估方法”等多项标准二十余项。参与多篇白皮书、调查报告等编制工作,包括《企业IT运维发展白皮书》《中国DevOps现状调查报告(2019年)》等。参与DevOps能力成熟度评估项目超过50个,具有丰富的标准编制及评估测试经验。
茹炳晟,业界知名实战派软件研发效能和软件质量领域专家,在国内外各大技术峰会上担任联席主席,国内外各大技术峰会的技术委员会成员及特定专题的出品人。现任腾讯技术工程事业群基础架构部首席研发效能架构师,腾讯研究院特约研究员。腾讯云最具价值专家TVP,阿里云最具价值专家MVP,华为云最具价值专家MVP,中国商业联合会互联网应用技术委员会智库专家,2020年度IT图书最具影响力作者,多本技术畅销书作者,Certified DevOps Enterprise Coach。
石雪峰,京东零售工程效能专家,专注于软件研发效能和数字化领域,Jenkins社区长期贡献者和全球大使,极客时间专栏《DevOps实战笔记》作者。
王晓翔,独立咨询师,去哪儿网工程效率部前高级总监,曾任奇安信内聘顾问,GOPS深圳大会金牌讲师,2019运维行业年度优秀技术专家,研发运营一体化(DevOps)能力成熟度标准咨询师。在软件配置管理、过程管理和工程效率方面有十几年的工作经验。曾在中国海关数据中心、索尼移动通信产品(中国)有限公司等多家公司工作。在去哪儿网供职七年间,逐步构建起持续集成、持续交付流水线,形成以应用为中心的全生命周期管理体系,并通过平台化不断为研发团队赋能,构建去哪儿网企业内部的DevOps生态圈,同时带领团队完成了从传统配置管理到工程效率团队的转型。
此外,畅销书《精益产品开发:原则、方法与实施》的作者何勉老师也对书中精益思想相关内容给予了具体的指导。博文视点张春雨老师的工作极为认真负责。高效运维社区、北京华佑科技有限公司在本书出版过程中亦给予了大力支持。在此对所有帮助本书写作和出版的朋友一并致谢。