想象一下，你在维护一个简单的个人网站。我们姑且把这称作编程，毕竟网站的实现包括一些使用 JavaScript 编写的脚本。你先登录服务器，修改了一处源代码，按下 Ctrl+S 组合键或其他快捷键，再使用浏览器访问你的网站，看到改动生效了。从软件开发的视角来看，你在完成了对源代码的修改之后，只需要“按个按钮”，瞬间就完成了软件发布。
这么看来，从修改完源代码到发布上线的过程是如此简单和快速，简直不值一提！呵呵，才不是这样的。在绝大多数严肃的软件开发场景中，从完成开发到发布上线需要的时间是以周为单位来计算的。
为什么这个过程会如此费时？
因为大家分头完成的对源代码的修改需要先汇聚到一起，再一起发布；
因为要把源代码编译打包，随后还要把安装包部署到服务器上并运行；
因为我们要做各种测试以保证质量；
因为要等到上线窗口才能发布；
因为领导要审批……
当我们分析某个团队的具体情况时，必然能看到由于各种各样的原因，最终会使得从修改完源代码到发布上线的这个过程需要一定的时间。
当我们说出这些原因的时候，内心充满自信和正义感：没错，就是因为这些原因，这很合理！
然而，《高质效交付：软件集成、测试与 发布精进之道》一书的作者们过去十几年在软件集成、测试、发布方面的工作经验来看，特别是以近五年来向数十家企业的众多软件开发团队提供DevOps咨询所积累的经验来看，从修改完源代码到发布上线的这个过程所需要的时间往往可以基于团队现状显著地缩短，这个过程所需要的人力投入也可以显著地减少。换句话说，软件交付过程的效率还可以大幅度地提升。
如何能做到这一点呢？是的，我们确实需要把大家对源代码的修改汇聚到一起；我们确实需要通过构建和部署，把源代码形态的软件转化为运行中的软件；们确实需要提升软件的质量直到可以交付给用户。这些都是我们必须完成的事情。然而如何高效率地完成这些事情却大有奥妙，其间往往有一处又一处可改进的空间。而改进的方法主要来自软件工程、敏捷、精益、持续集成、持续交付、DevOps、云原生、研发效能、平台工程等，它们都或多或少地涉及软件交付过程，告诉你软件交付过程该怎么做。
本书作者在向各企业、各开发团队提供咨询服务时，并不囿于上述某个“门派”：不会要求客户比照云原生十二因素逐项整改；不会因为“原教旨义”的持续集成提倡把代码改动直接提交到集成分支，而将客户使用特性分支的方案视为旁门左道。同样地，本书的作者在书中也不会这样做。书中综合应用各家核心思想，讲解在今时今日具体该怎么做，才能取得最好的效果。我们本着务实的精神，不管白猫黑猫，只要能提高集成、测试、发布的效率，就是好猫。
市面上有不少好书，专精于特定的活动，如构建、单元测试，或者专精于特定的工具，如 Git、Kubernetes。本书不是这样的书。对软件交付过程中各个具体活动、具体工具的详细讲解不是本书的重点，本书只会讲解其中的要点。否则，本书将厚达几千页，恐怕永远也无法交稿。本书关注的重点是各项活动应该在何时何处发生，应该如何统筹协调、合理安排，各个工具应该在何时何处使用以实现最大的效益。
社区赠书
最后，本次福利将送出：《高质效交付：软件集成、测试与 发布精进之道》 * 5 本
截止时间：还需要支付积分，就还有赠书额度，先到先得
领取方式：
- 支付积分即可兑换，复制 “ 积分支付订单号 ”
- 在本站中私信我这些内容：积分支付订单号、活动书名、快递信息（姓名、电话、地址）
暂无评论内容