概念
持续交付建立在持续集成基础上，将集成后的代码部署到更贴合近真实运行环境的[类生产环境]中。给测试团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付优先于整个产品生命周期软件部署，建立在高水平自动化持续集成之上。
目的
持续交付用来确保让代码能够快速、安全的部署到产品部署中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。
向前看是持续集成，向后看是持续交付！
持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。
如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题，可以继续手动部署到生产环境中。
优点
- 快速发布。能够应对业务要求，并更快地实现软件价值；
- 编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈；
- 高质量的软件发布标准。整个交付过程标准化、可重复、可靠
- 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
条件
- 对软件组件的开发和平台的供应和设置进行持续集成。
- TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对：TDD 是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法（单元测试使得问题的修复过程比集成测试或功能测试容易很多）。
- 代码审阅！至少要进行代码审阅……如果能进行结对编程（Pair programming）当然就更好了。
- 软件的持续审计 - 例如使用 Sonar。
- 在生产级环境实现功能测试的自动化。
- 更强大的非功能测试自动化（性能、可用性等）。
- 独立于目标环境的自动化打包和部署。
- 管理重大功能和演进时，还需要具备健全的软件开发实践，例如零停机部署技术。