上期回顾
上期，我们介绍了无从下手的第一个原因：对于软件交付本身缺少一个正确的认知。我们认为软件交付的过程就像是拍连续剧的过程，而不是盖房子的过程。
本期内容
本期介绍持续交付的八大原则。没有掌握它即是我们无从下手的第二个原因。
软件交付的原则
不同的软件交付的认知， 决定不同的软件交付方式。
不同的软件交付的认知，决定了不同的软件交付方式，而不同的软件交付方式决定了软件交付的原则。
从软件交付方式的演进历程来看，软件交付方式之间的区别在于以下几个维度的假设：
- 在前期是否知道构建什么样的软件；
- 软件交付是否频繁；
- 交付团队是否为产品结果负责。
这几个假设的两个极端分别：瀑布模型和持续交付。显然，如果你认为软件交付像盖房子，那么，你会选择瀑布模型；如果你认为软件交付像拍连续剧，那么，你会选择持续交付。
在实际工作中，如果你希望落地DevOps，你的软件交付方式必然选择的是持续交付。
那么，问题来了，我们该如何实践持续交付呢？笔者认为需要从两个层面入手：1. 技术层面；2. 管理层面。
管理层面不是本期的内容。这里有一个小经验分享，在实践持续交付一段时间后，你会发现它会向管理侧进行延伸只是时间问题。
在技术层面，以下两点是我们实践持续交付的要点：
- 将《持续交付》和《持续交付2.0》这两本书看两遍。
- 牢牢掌握持续交付的八大原则，并深知原则背后的原理；在遇到任何软件交付相关问题时，优先以这些原则作为指导意见。
为什么掌握持续交付的原则如此重要？不同的软件系统就像不同的连续剧，没有一部剧是相同的。只有掌握原则，才能让我们以不变应万变。一家公司里中持续交付的实施步骤是ABC，但是在另一家公司可能就是ACB了。
持续交付的八大原则如下：
- 为软件的发布创建一个可重复且可靠的过程；
- 将几乎所有事情自动化；
- 把所有的东西都纳入版本控制；
- 提前并频繁地做让你感到痛苦的事；
- 内建质量；
- 完成（DONE）意味着“已发布”；
- 交付过程是每个成员的责任；
- 持续改进。
该如何理解这些原则呢？
这些原则之间是有相关性的，把握相关性，可以让我们更容易理解它们。
为方便大家理解，我画了一幅的持续交付八大原则关系图：
我们可以分多个版本来看这关系图。
详细版本：
创建一个可重复且可靠的软件交付过程是八大原则的核心（原则1）。软件交付过程如何做到可重复？即要做到将几乎所有的事情都自动化（原则2）。所有的事情包括了构建、测试、部署等工程方面的内容。软件交付过程如何做到可靠呢？即将所有的东西都纳入版本控制（原则3）、内建质量（原则5）。
关于为什么要将所有的东西都纳入版本控制，我们后面会有一期专门来讲。请关注我的公众号：持续交付实践指南。
什么是内建质量？当你把质量看作是团队中每个人的责任时，同时，测试不是一个阶段时，团队就做到了内建质量。
当我们把质量看作是每个人的责任时，就意味着交付过程是每个人的责任（原则7）。
要做到原则7，团队的成员就必须达成共识：将“完成（DONE）”定义为“已发布”上线（原则6），这样，团队的人就会从需求，开发跟进到功能发布。
持续交付原则为什么要求我们提前并频繁地做让你痛苦的事情（原则4）？我们拿健身来比喻。健身说到底就是撕裂肌肉，肌肉再生长的过程。这个过程很痛苦。这种痛苦，没有健过身的人可能体会不到。那么想象一下那种长期不运动的人，某一天突然让你做100个俯卧撑，然后你第二天那种肌肉酸痛的感觉。
虽然痛苦，但是你看那些经常健身的人，都是非常强壮的。这个道理放在软件交付领域也是一样的。交付越频繁，你的软件就越健壮。总之，这一原则是在增强你的软件系统的反脆弱能力。
我见过一些团队，他们将“持续交付”看作是一个项目。项目完成之时即是持续交付的结束之时。还是拿健身来做比喻。健身也是需要持续进行的。间隔4年不健身，肌肉也会萎缩的。这就是为什么我们要持续改进。
精简版：
如果要精简持续交付八大原则，你可以这么理解：为软件发布创建一个可重复的过程要求我们将几乎所有事情自动化。如果要做到可靠，我们还必须做到内建质量以及把所有的东西都纳入版本控制。其它的原则是你在创建这个过程本身时，相对偏非技术层面的事情。但并不是说它不重要。
不能再精简版：
如果还要继续精简持续交付的八大原则，那么，你只需要记住一切自动化，一切版本化。不过，也要记住，它只是起点。
说到这里，我们的持续交付八大原则已经讲完了。我相信大部分人还是一头雾水，没有关系，你不可能花10分钟理解别人花几年时间总结出来的结晶。
我会在持续交付实践指南系列教程中用实例带领大家实践这些原则。
下期预告：DevOps的定义
