持续交付的八条原则，你能做到几条？

     英文原文：    <a href="/misc/goto?guid=4958185827717796191" target="_blank">8 Principles of Continuous Delivery</a>    <ol>     <li><strong>The process for releasing/deploying software MUST be repeatable and reliable</strong><strong style="padding-bottom:0px;margin:0px;padding-left:0px;outline-width:0px;padding-right:0px;font-family:inherit;font-size:12px;vertical-align:baseline;padding-top:0px;">.<br /> </strong>软件的发布或部署过程必须是可重复且可靠的。这就引出了下一条…</li>     <li><strong>Automate everything!</strong> <br /> 所有操作的自动化！我很难相信“手工操作是可重复且可靠的”这种说法。所以一定要将所有重复性的操作变成自动化的，从而变得可靠。</li>     <li><strong>If somethings difficult or painful, do it more often.</strong><br /> 如果某件事情做起来很困难或者让你觉得很痛苦，那么就尽早且尽可能频繁地去做。乍一看上去，这么做太蠢了，因为人的直觉反应是：应该推迟这件事。然而，实际上，这句话是说：如果做某件事很痛苦，一旦要求自己更频繁地做，你就会有动力想出各种办法，来解决这个痛苦，很可能把它变成了自动化的，最终会把它变成一件简单容易的事情。就拿更新数据库结构来说吧。一般来说，没人想频繁地修改它，所以就会尽可能推迟或少做，比如一个月做一次更新，或者更长。然而，你真正需要做的却是改进数据库结构调整的流程，让它变成更容易，更频繁。甚至如果必要的话，可以一天做一次。</li>     <li><strong>Keep everything in source control</strong><br /> 对所有内容进行版本控制。当今软件行业还在强调这种要求，你可能会觉得奇怪，谁现在还没有用版本控制呢？但是，我指的不仅仅是源代码哟，还包括环境、配置、数据等等。</li>     <li><strong>Done means “released”</strong>.<br /> 完成意味着“已发布”。也就是说，项目的“完成”是指把它交到用户手中，并且可以正常工作。而不是“我已经提交了，后面的我不管了”，或者“我已经提测啦”，或者“我测试完了，没有问题。”</li>     <li><strong>Build quality in!</strong><br /> 内建质量。在质量度量方面花一点儿精力。从长期维护的角度来讲，具有良好质量度量目标的项目（如单元测试覆盖、代码风格、复杂度等等） 要比没有这些度量的项目更容易一些。</li>     <li><strong>Everybody has responsibility for the release process.</strong><br /> 每个人都要对交付过程负责。在开发人员机器上运行的程序不会为公司带来收益。没有部署的项目也一样。开发人员也应该时刻想着如何部署手中的软件。项目经理也应该关注什么时间部署。测试人员也应该进行部署测试。</li>     <li><strong>Improve continuously.</strong><br /> 持续改进。软件开发如“逆水行舟”，不进则退。持续改进意味着，你的系统需要一直改进，这样当需要时，才能很容易修改。</li>    </ol>    <p><strong>转自：</strong><a href="/misc/goto?guid=4958185828461351700"><strong>http://www.continuousdelivery.info/index.php/2011/08/09/8_principles_of_cd/</strong></a></p>