想象一下，你在维护一个简单的个人网站。我们姑且把这称作编程，毕竟网站的实现包括一些使用 JavaScript 编写的脚本。你先登录服务器，修改了一处源代码，按下 Ctrl+S 组合键或其他快捷键，再使用浏览器访问你的网站，看到改动生效了。从软件开发的视角来看，你在完成了对源代码的修改之后，只需要“按个按钮”，瞬间就完成了软件发布。
这么看来，从修改完源代码到发布上线的过程是如此简单和快速，简直不值一提！呵呵，才不是这样的。在绝大多数严肃的软件开发场景中，从完成开发到发布上线需要的时间是以周为单位来计算的。
为什么这个过程会如此费时？
因为大家分头完成的对源代码的修改需要先汇聚到一起，再一起发布；
因为要把源代码编译打包，随后还要把安装包部署到服务器上并运行；
因为我们要做各种测试以保证质量；
因为要等到上线窗口才能发布；
因为领导要审批……
当我们分析某个团队的具体情况时，必然能看到由于各种各样的原因，最终会使得从修改完源代码到发布上线的这个过程需要一定的时间。
当我们说出这些原因的时候，内心充满自信和正义感：没错，就是因为这些原因，这很合理！
然而，《高质效交付：软件集成、测试与 发布精进之道》一书的作者们过去十几年在软件集成、测试、发布方面的工作经验来看，特别是以近五年来向数十家企业的众多软件开发团队提供DevOps咨询所积累的经验来看，从修改完源代码到发布上线的这个过程所需要的时间往往可以基于团队现状显著地缩短，这个过程所需要的人力投入也可以显著地减少。换句话说，软件交付过程的效率还可以大幅度地提升。
如何能做到这一点呢？是的，我们确实需要把大家对源代码的修改汇聚到一起；我们确实需要通过构建和部署，把源代码形态的软件转化为运行中的软件；们确实需要提升软件的质量直到可以交付给用户。这些都是我们必须完成的事情。然而如何高效率地完成这些事情却大有奥妙，其间往往有一处又一处可改进的空间。而改进的方法主要来自软件工程、敏捷、精益、持续集成、持续交付、DevOps、云原生、研发效能、平台工程等，它们都或多或少地涉及软件交付过程，告诉你软件交付过程该怎么做。
本书作者在向各企业、各开发团队提供咨询服务时，并不囿于上述某个“门派”：不会要求客户比照云原生十二因素逐项整改；不会因为“原教旨义”的持续集成提倡把代码改动直接提交到集成分支，而将客户使用特性分支的方案视为旁门左道。同样地，本书的作者在书中也不会这样做。书中综合应用各家核心思想，讲解在今时今日具体该怎么做，才能取得最好的效果。我们本着务实的精神，不管白猫黑猫，只要能提高集成、测试、发布的效率，就是好猫。
市面上有不少好书，专精于特定的活动，如构建、单元测试，或者专精于特定的工具，如 Git、Kubernetes。本书不是这样的书。对软件交付过程中各个具体活动、具体工具的详细讲解不是本书的重点，本书只会讲解其中的要点。否则，本书将厚达几千页，恐怕永远也无法交稿。本书关注的重点是各项活动应该在何时何处发生，应该如何统筹协调、合理安排，各个工具应该在何时何处使用以实现最大的效益。
本书分为 6 部分。
第 1 部分带大家进入软件交付情境，将介绍软件交付过程的范围和内容，以及软件交付过程的追求目标。
第 2 部分是对软件交付总体过程的介绍和讨论。这部分将不仅讲解持续集成、持续交付这两个经典方法，讲解敏捷、精益等思想的应用，也将讲解在实践中涌现出的对经典方法和思想的调整、完善和发展。总之，我们将在这部分搭起软件交付总体过程的框架。
第 3 部分到第 5 部分将介绍软件交付过程中诸多具体活动的要点。第 3 部分将讲解版本控制、使用版本控制工具、分支策略、使用制品管理工具等内容。第4 部分将讨论构建、构建环境、部署、运行环境、SQL 变更、应用配置参数等内容。第 5 部分将首先介绍各类测试，然后介绍测试通用要点和测试通用策略，最后介绍缺陷修复。
第 6 部分补充了一些全局性内容，如组织结构与人员职责，这有利于高效交付的组织结构的设计。作为本书最后一部分，第 6 部分还总结了全书。
还有一些更“杂”的内容放在了附录中。例如，如果你对软件工程、敏捷、精益、DevOps 之类的词汇感到陌生，那么可以先跳到附录 A 了解一下。
下面，让我们一起踏上软件交付之旅吧。
好啦，本周送书环节又来啦～小伙伴们随便留言，松哥会选出三位幸运小伙伴，各送一本《高质量交付》，包邮到家！
