持续交付的8条原则

1. 软件的发布或部署过程必须是可重复且可靠的。这就引出了下一条…
2. 所有操作的自动化！我很难相信“手工操作是可重复且可靠的”这种说法。所以一定要将所有重复性的操作变成自动化的，从而变得可靠。
3. 如果某件事情做起来很困难或者让你觉得很痛苦，那么就尽早且尽可能频繁地去做。乍一看上去，这么做太蠢了，因为人的直觉反应是：应该推迟这件事。然而，实际上，这句话是说：如果做某件事很痛苦，一旦要求自己更频繁地做，你就会有动力想出各种办法，来解决这个痛苦，很可能把它变成了自动化的，最终会把它变成一件简单容易的事情。就拿更新数据库结构来说吧。一般来说，没人想频繁地修改它，所以就会尽可能推迟或少做，比如一个月做一次更新，或者更长。然而，你真正需要做的却是改进数据库结构调整的流程，让它变成更容易，更频繁。甚至如果必要的话，可以一天做一次。
4. 对所有内容进行版本控制。当今软件行业还在强调这种要求，你可能会觉得奇怪，谁现在还没有用版本控制呢？但是，我指的不仅仅是源代码哟，还包括环境、配置、数据等等。
5. 完成意味着“已发布”。也就是说，项目的“完成”是指把它交到用户手中，并且可以正常工作。而不是“我已经提交了，后面的我不管了”，或者“我已经提测啦”，或者“我测试完了，没有问题。”
6. 内建质量。在质量度量方面花一点儿精力。从长期维护的角度来讲，具有良好质量度量目标的项目（如单元测试覆盖、代码风格、复杂度等等） 要比没有这些度量的项目更容易一些。
7. 每个人都要对交付过程负责。在开发人员机器上运行的程序不会为公司带来收益。没有部署的项目也一样。开发人员也应该时刻想着如何部署手中的软件。项目经理也应该关注什么时间部署。测试人员也应该进行部署测试。
8. 持续改进。软件开发如“逆水行舟”，不进则退。持续改进意味着，你的系统需要一直改进，这样当需要时，才能很容易修改。

原文：http://www.dzone.com/links/r/the_8_principles_of_continuous_delivery.html