介绍

软件发布是一个令人头痛的过程，非常耗时且风险很高。本书独特而有条理地阐述了以快速、高效、可靠的方式向用户交付新功能的原则和技术实践。通过实现自动化的构建、部署和测试过程，并改进开发人员、测试人员、运维人员之间的协作，交付团队可以在几小时（甚至几分钟）内发布软件变更，而这不受项目大小和代码复杂性的影响。
——《持续交付》

不论你在什么样的团队，都需要为用户提供价值，即交付可用的软件。而这就是一本讲述如何高效交付软件的书。

Git 的多分支开发是邪恶的！ 想知道为什么吗？直接看 分支开发的问题。

副标题

  • 英文版副标题：Reliable Software Releases through Build, Test, and Deployment Automation
  • 中文版副标题：发布可靠软件的系统方法

我非常喜欢中文版的副标题，精准地概括了本书的全部内容，而英文版只是阐述了一个流程。感觉是缺少了这个更深层次的含义：系统化的方法。

软件交付的问题

  • 反模式：手工部署软件
  • 反模式：开发完成之后才向类生产环境部署
  • 反模式：生产环境的手工配置管理

这些反模式是真的发生在现实工作当中的例子，有可能你现在还在经历这种事情……

软件交付的原则

  • 为软件的发布创建一个可重复且可靠的过程
  • 将几乎所有事情自动化
  • 把所有的东西都纳入版本控制
  • 提前并频繁地做让你感到痛苦的事

坚持这些原则可以解决大多数问题。

依赖管理

需要记录所有的依赖版本，甚至包括操作系统。以前我也觉得这个没什么用，直到遇到了 Unity 5.3 不支持 macOS Mojave 的 APFS 文件系统，这才意识到这是多么重要的事情。

  • 例如现在各大操作系统都抛弃了对 Python 2.x 的支持。
  • macOS Catalina 取消了 32 位程序的支持。

构建与部署的脚本化

构建脚本需要使用胶水语言，需要这个语言支持跨平台、生态完善、简单易用。

说实话，Python 真是不二之选，第三方的生态实在是太完善了，你可以找到任何你需要的功能，例如：操作进程的跨平台库、各种 JSON YAML 之类的解析库、FTP 支持、SSH 支持等等……

而其他的 JavaScript、Lua、Ruby、Perl、Shell 都各有各的问题，难堪大用。

分支开发的问题

由于 Git 的流行，现在大部分人最常遇到的问题是如何做分支开发，持续集成如何与不同分支结合在一起使用。

首先要明白，项目需求决定了集成工作量。分支只是将项目需求及对应的集成工作量延迟了，最终分支在合并到主干时集成工作才开始。

同样的需求会有同样的集成工作量，不管是在主干上还是分支上，只不过在分支上开发会推迟集成工作，但不会减少集成工作量。

而这就是为什么很多团队一发布版本就要通宵加班的原因，因为有大量的集成工作需要在发布版本时处理。 这样的团队往往是坚定的多分支开发拥护者，坚定地要求主干与发布分支完全分离，发布分支上的提交必须经过拣选手动从主干合并到发布分支。

这时，主干开发就可以帮忙解决问题了，将大部分工作放在主干上提交，可以保证代码被持续集成、开发人员及时获得他人的修改、避免项目后期的“合并地狱”和“集成地狱”。 同时主干开发也给出了如何不用分支也可以做复杂修改的方法。同时也给出了按发布创建分支的最佳实践方法，主干开发并不是排斥分支，只有当不需要合并回主干时才创建分支。

可惜的是主干开发是 14.6 节，几乎在书的最末尾，很少有人能读完全书看到这个重要的东西。

心得

你能控制的越多，越能系统性的解决问题，越能从更高的层面解决问题，越能轻松且正确地解决问题。如果你权限有限，那么很难实行持续交付。

持续交付的思想就是增加快速迭代反馈的能力。其实核心非常简单，简单说就是及时做该做的工作、不要推迟，持续集成、主干开发就是这个思路的产物。

京东购买链接

如果你对持续集成、持续交付感兴趣，如果你想要在全栈工程师，那么这是一本必读的书：

现实

看完这本书，你就能轻松地回答下面这些人们在现实中遇到的问题了：

使用关键词 分支 部署 site:v2ex.com 可以用 Google 找到更多相关结果。

哪怕不看这本书，你也可以浏览一下上面的链接，看看能不能想清楚如何解决他们提出的问题。

参考资料