推荐序
近年来关于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基金会中国区执行董事