持续交付是一种软件开发规范，依照这种规范软件可以在任何时候被发布到生产。
持续交付满足以下条件：
- 你的软件在整个生命周期内是可以被部署的
- 你的团队把保持软件可部署工作放在开发新功能的前面
- 在生产发生变更时，关于生产的状态任何人都可以得到快速、自动的反馈
- 在任意环境部署任意版本只需要简单的点下按钮
通过开发团队在不同的环境持续的集成、编译和执行自动化测试，来完成支持交付。更进一步，将可执行文件放在准生产环境中测试来保证软件在生产环境可用。为了做到这些，你需要使用DeploymentPipeline。
测试的关键是商业赞助商要求当前开发版本马上部署到生产环境，但没人会担心这一点。
为了达到CD的要求，你需要：
- 在软件交付中的每个人可以亲密的合作，可以参考DevOpsCulture
- 交付过程中的所有操作都可以被大量的自动化，通常使用DevOpsCulture
持续交付（Continuous Delivery）通常会和持续部署（Continuous Deployment）混淆。持续部署表示每一个变更会通过pipeline并会自动应用到生产环境，意味着每一天会有很多次的生产部署。持续交付意味着你可以做到频繁的部署，但可以选择不这样做，这取决于商业上的逻辑，可能希望晚点部署。为了达到持续部署，你必须先完成持续交付。
持续集成 是在开发环境中集成、编译、测试等。而持续交付建立在这个上面，针对的是生产部署的环节。
持续交付的好处有：
- 减少部署的风险 ：由于部署的制品变更很少，出错的可能性也小，如果出错也很容易修复。
- 进度可靠：许多人以工作完成情况来过跟踪进度。如果“完成”只是开发口头上说的完成，这并不比软件可以被部署到生产环境可行。
- 用户反馈 ：软件开发最大的风险是开发的东西不满足客户要求。越早可以让客户用到产品，就可以越早的听到有价值的反馈意见（通常需要使用ObservedRequirements）
如果你不想让所有的客户同时都使用新的软件，你可以只让部署对部分客户生效，然后一些主要的客户，最后是所有客户。
