持续交付的目标是基于不断变化的需要进行的生产活动：即自动化的软件生产线。保证该活动的核心概念是持续交付Pipeline，其将软件交付的过程分为若干个不同的阶段。每个阶段从不同的角度来验证新功能的质量，以避免出现影响用户的错误。
Pipeline应当在功能交付的过程中为团队提供反馈和变更过程的可见性。通常典型的持续交付Pipeline可以分为以下几个阶段：
- 初始阶段--构建自动化和持续集成
Pipeline开始为后续的阶段提供可执行的二进制交付物。新开发的功能应当集成到代码主干，执行构建和单元测试，这些工作可以持续反映当前应用开发代码的健康情况。
- 验证阶段--测试自动化
所有相关的方面，如功能性，安全性，性能或者合规性都需要由Pipeline进行验证。该阶段可能涉及不同类型的自动或者手工工作，亦或是需要人员授权。
- 应用系统推出阶段--部署自动化
持续交付Pipeline最后的阶段是部署到生产环境。由于前期各阶段的系统质量得到了验证，现在到了本阶段风险大大降低了。部署也可以分阶段进行，可以先发布到生产环境中一个系统功能子集，而后监控运行情况，如果运行正常则可以完全发布到生产。部署应当是自动化的，交付的新功能应该在几分钟内让用户可用。
- 基础平台设置
部署Pipeline由平台设置与系统配置管理所支撑，平台设置和配置管理能够使团队自动化创建、维护以及删除完整的环境，甚至是一键触发。自动化的平台设置能够确保所有的测试能够正确执行且测试环境可以重现。而且，还有利于横向扩展。
- 编排所有--发布协作
- 在质量达标之前不要添加新功能
在一般的传统环境下，开发团队试图一口气实现整个新版本的所有功能，并达到所有关于软件质量特点的健壮性、可扩展性和可维护性等要求。只需一次，项目就接近完工。据此，软件只有达到能够发布给客户的状态，才能够在项目结束时发挥商业价值。随着项目最后期限临近以及预算压力增加，项目质量往往首先成为被妥协的对象。
采用了“质量达标前不添加新功能”的原则可以避免交付质量差、用户满意度低和补丁满满的系统。持续交付要求从一开始，每个新功能都要求满足预先设定的质量标准。