“持续交付”定义为“一套软件工程方法论和许许多多的最佳实践的集合”。

持续集成、持续交付和持续部署的关系

通常会把软件研发工作拆解，拆分成不同模块或不同团队后进行编码，编码完成后，进行集成构建和测试。这个从编码到构建再到测试的反复持续过程，就叫作“持续集成”。

在“持续集成”之后，获取外部对软件的反馈再通过“持续集成”进行优化的过程就叫作“持续交付”，它是“持续集成”的自然延续。

“持续部署”又是什么呢？软件的发布和部署通常是最艰难的一个步骤。

“持续部署”就是将可交付产品，快速且安全地交付用户使用的一套方法和系统，它是“持续交付”的最后“一公里”。

“持续交付”是一个承上启下的过程，它使“持续集成”有了实际业务价值，形成了闭环，而又为将来达到“持续部署”的高级目标做好了铺垫。

从“持续部署”（自动化发布）开始推进“持续交付”，这才是一条优选的路径。

持续交付的显性价值

持续交付也通常以“发布流水线”的方式来解释，即研发团队从开发，到测试，再到部署，最终将产品交付给最终用户使用的过程。

通过持续交付新的软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响。这里说的“软件价值”，说白了就是收入、日活、GMV 等 KPI 指标了。

通常我们在实施持续交付后，都能够做到在保证交付质量的前提下，加快交付速度，从而更快地得到市场反馈，引领产品的方向，最终达到扩大收益的目的。

持续交付的能力，正成为评定一家互联网公司研发能力的重要指标。

如果你是 CTO 或者是一个较大规模研发团队的管理者

你是不是时常困扰于技术选型的问题？

技术选型最大的难点在于影响大，又难以验证（或者验证效率低下）。而造成这些困境的绝大多数原因是没有合适的测试环境，比如环境差异造成测试数据缺乏说服力，又比如缺少隔离环境造成服务冲突等等。而这正是持续交付的用武之地。持续交付的实施，将全面改善企业对测试环境的管理方法，使得环境管理更合理、更自由。

你是不是经常头痛于已制定的标准难以落地？

标准、规范、流程的落地，都需要载体，而最好的载体就是平台工具。而持续交付是一整套平台工具的落地，几乎涵盖了研发的整个生命周期，是天然的、最佳的载体。另外，持续交付的落地本身就伴随着各类标准、规范、流程的制定和实施，可以说两者相互依存，是非常好的管理思想落地方案。

你是不是时常考虑如何提高跨部门协作的效率？

我看到的每一个持续交付实施团队，都可以说是最厉害的“拆墙大队”，拆的就是各个研发协作部门间的“隔离墙”。持续交付能够向各个协作部门输出统一的标准、流程和工具，提升沟通效率；并且通过大量的自动化，进一步提升各部门工作效率；还可以快速集成，把各个分散的团队，无论是横向的业务研发团队，还是纵向的技术框架团队，紧紧地联系在一起，共同进退。

你是不是担心“黑天鹅”的降临？

既然叫“黑天鹅”，那就是说明它的产生有一定的必然性。正应了一句老话“是福不是祸，是祸躲不过”，既然躲不过，那就解决它呗。其实任何故障都有一个天敌，叫作：快速恢复。假设，所有的故障都可以在 3 分钟内恢复，你是不是觉得天下无敌了。那恢复故障最快、最有效的手段又是什么呢？当然就是回滚（或重新部署）了，而这正是持续交付所包含和着力打造的能力之一。

如果你是 Team Leader

你一定希望团队的知识能够传承。

互联网公司的人才流动之频繁已经远远超过了你我的想象。人来人往，如何将知识传承下来呢？其实在这方面，持续交付也能为团队提供很多帮助。首先，持续交付将团队赖以生存的工作流程进行了固化；其次，利用代码静态检查等工具，能够很好地传承团队多年来的代码规范，并作为检查项进行自动化校验；再次，自动化测试的脚本，同样是团队经验的产物。

你一定希望团队专注于业务而非工程。

目前越来越多的公司或研发组织意识到，持续交付体系也如同中间件一样，能够从日常的业务研发工作中抽象出来，其不同只在于中间件解决架构问题，而持续交付解决工程问题。这样研发团队能够全力应付业务的需求，而不用总是重复奔波于一些烦人且耗时的工程问题，比如安装测试机、准备编译服务器等等。

你一定希望以一个较平稳的节奏持续工作。

虽然在实施持续交付的初期，团队为了适应新的流程和工具，会有一定的效率下降，但之后在自动化的帮助下，团队效率会有一个明显的提升并逐渐稳定下来。持续交付就是这样通过稳固的流程、自动化的工具和公开而真实的数据，来避免发布前夕容易发生的“死亡行军”式开发阶段。

如果你是产品经理

你应该是产品真正的第一个用户。

持续交付不仅仅是可以保证每一个变化都能及时得到测试以及反馈，更多的是解决测试与实际发布时存在差异的问题。产品人员再也不会陷入“为什么用户端运行的结果，和在测试环境中的不一致”这样的窘境，他们将真正成为第一个用户，而不再是最后一个 QA。

你应该完全知悉当前的进度和质量。

作为产品人员，你是不是一直有这样的感觉：和研发团队之间总有一扇墙，程序员们似乎并不乐意告诉产品人员项目的真相；而最终总有这样那样的理由造成延期，产品人员往往无话可说。那么，持续交付就能够实时地反应当前的开发情况，从而帮助产品人员决策和调整。

你的产品应该随时能发布。

计划永远赶不上变化，任何产品人员都希望自己的产品能够随时处于可发布状态。这样就能灵活地交付已完成的功能，迎合市场或业务的需要。本质上，做到代码上线和业务上线的解耦分离，这也正是持续交付方法论强调的一个重点。

如果你是一个程序员。

你可以通过对持续交付的学习，进一步加强自己对整个软件工程的认识。

持续交付涵盖了软件交付端到端的整个周期，其覆盖面不仅仅包括编码，还包括：设计、测试、部署、运维、运营等等。如果你对自己的发展有更高的要求，那么你就应该学习一下持续交付的内容，它能让你看到更多与编码有关的其他东西，比如不同的编码方式等；也能让你站在更高的角度去看待自己的工作：研发效率的提高往往不是个人能力的提高，而是集体协同效率的提高。

你可以利用持续交付的工具或最佳实践，提高自己的工作效率和质量。

随着持续交付的流行，其配套的实践和工具也层出不穷。如果你玩过 ping-pong 式的结对编程（A 写测试，B 写实现，然后 B 写下一个测试，A 写重构和实现），你一定会觉得编程如此轻松有趣，而这种 TDD 的方式也很好的保证了代码质量。

你可以参与到持续交付实施中去，享受为其他程序员提供效率工具的挑战和乐趣。

试想一下，如果你是一个出租车司机，而你的乘客却是舒马赫（F1 世界冠军），此时你开车的压力会有多大。其实参与到持续交付的实施中也是一样，因为你正在用程序员的方式改造程序员的工作习惯，为程序员提供工具。虽然挑战和压力巨大，但这又是如此有趣，你将会站在另一个高度去看你曾经的工作。（转自Lomo）

“持续交付”定义为“一套软件工程方法论和许许多多的最佳实践的集合”。

持续集成、持续交付和持续部署的关系

通常会把软件研发工作拆解，拆分成不同模块或不同团队后进行编码，编码完成后，进行集成构建和测试。这个从编码到构建再到测试的反复持续过程，就叫作“持续集成”。

在“持续集成”之后，获取外部对软件的反馈再通过“持续集成”进行优化的过程就叫作“持续交付”，它是“持续集成”的自然延续。

“持续部署”又是什么呢？软件的发布和部署通常是最艰难的一个步骤。

“持续部署”就是将可交付产品，快速且安全地交付用户使用的一套方法和系统，它是“持续交付”的最后“一公里”。

“持续交付”是一个承上启下的过程，它使“持续集成”有了实际业务价值，形成了闭环，而又为将来达到“持续部署”的高级目标做好了铺垫。

从“持续部署”（自动化发布）开始推进“持续交付”，这才是一条优选的路径。

持续交付的显性价值

持续交付也通常以“发布流水线”的方式来解释，即研发团队从开发，到测试，再到部署，最终将产品交付给最终用户使用的过程。

通过持续交付新的软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响。这里说的“软件价值”，说白了就是收入、日活、GMV 等 KPI 指标了。

通常我们在实施持续交付后，都能够做到在保证交付质量的前提下，加快交付速度，从而更快地得到市场反馈，引领产品的方向，最终达到扩大收益的目的。

持续交付的能力，正成为评定一家互联网公司研发能力的重要指标。

如果你是 CTO 或者是一个较大规模研发团队的管理者

你是不是时常困扰于技术选型的问题？

技术选型最大的难点在于影响大，又难以验证（或者验证效率低下）。而造成这些困境的绝大多数原因是没有合适的测试环境，比如环境差异造成测试数据缺乏说服力，又比如缺少隔离环境造成服务冲突等等。而这正是持续交付的用武之地。持续交付的实施，将全面改善企业对测试环境的管理方法，使得环境管理更合理、更自由。

你是不是经常头痛于已制定的标准难以落地？

标准、规范、流程的落地，都需要载体，而最好的载体就是平台工具。而持续交付是一整套平台工具的落地，几乎涵盖了研发的整个生命周期，是天然的、最佳的载体。另外，持续交付的落地本身就伴随着各类标准、规范、流程的制定和实施，可以说两者相互依存，是非常好的管理思想落地方案。

你是不是时常考虑如何提高跨部门协作的效率？

我看到的每一个持续交付实施团队，都可以说是最厉害的“拆墙大队”，拆的就是各个研发协作部门间的“隔离墙”。持续交付能够向各个协作部门输出统一的标准、流程和工具，提升沟通效率；并且通过大量的自动化，进一步提升各部门工作效率；还可以快速集成，把各个分散的团队，无论是横向的业务研发团队，还是纵向的技术框架团队，紧紧地联系在一起，共同进退。

你是不是担心“黑天鹅”的降临？

既然叫“黑天鹅”，那就是说明它的产生有一定的必然性。正应了一句老话“是福不是祸，是祸躲不过”，既然躲不过，那就解决它呗。其实任何故障都有一个天敌，叫作：快速恢复。假设，所有的故障都可以在 3 分钟内恢复，你是不是觉得天下无敌了。那恢复故障最快、最有效的手段又是什么呢？当然就是回滚（或重新部署）了，而这正是持续交付所包含和着力打造的能力之一。

如果你是 Team Leader

你一定希望团队的知识能够传承。

互联网公司的人才流动之频繁已经远远超过了你我的想象。人来人往，如何将知识传承下来呢？其实在这方面，持续交付也能为团队提供很多帮助。首先，持续交付将团队赖以生存的工作流程进行了固化；其次，利用代码静态检查等工具，能够很好地传承团队多年来的代码规范，并作为检查项进行自动化校验；再次，自动化测试的脚本，同样是团队经验的产物。

你一定希望团队专注于业务而非工程。

目前越来越多的公司或研发组织意识到，持续交付体系也如同中间件一样，能够从日常的业务研发工作中抽象出来，其不同只在于中间件解决架构问题，而持续交付解决工程问题。这样研发团队能够全力应付业务的需求，而不用总是重复奔波于一些烦人且耗时的工程问题，比如安装测试机、准备编译服务器等等。

你一定希望以一个较平稳的节奏持续工作。

虽然在实施持续交付的初期，团队为了适应新的流程和工具，会有一定的效率下降，但之后在自动化的帮助下，团队效率会有一个明显的提升并逐渐稳定下来。持续交付就是这样通过稳固的流程、自动化的工具和公开而真实的数据，来避免发布前夕容易发生的“死亡行军”式开发阶段。

如果你是产品经理

你应该是产品真正的第一个用户。

持续交付不仅仅是可以保证每一个变化都能及时得到测试以及反馈，更多的是解决测试与实际发布时存在差异的问题。产品人员再也不会陷入“为什么用户端运行的结果，和在测试环境中的不一致”这样的窘境，他们将真正成为第一个用户，而不再是最后一个 QA。

你应该完全知悉当前的进度和质量。

作为产品人员，你是不是一直有这样的感觉：和研发团队之间总有一扇墙，程序员们似乎并不乐意告诉产品人员项目的真相；而最终总有这样那样的理由造成延期，产品人员往往无话可说。那么，持续交付就能够实时地反应当前的开发情况，从而帮助产品人员决策和调整。

你的产品应该随时能发布。

计划永远赶不上变化，任何产品人员都希望自己的产品能够随时处于可发布状态。这样就能灵活地交付已完成的功能，迎合市场或业务的需要。本质上，做到代码上线和业务上线的解耦分离，这也正是持续交付方法论强调的一个重点。

如果你是一个程序员。

你可以通过对持续交付的学习，进一步加强自己对整个软件工程的认识。

持续交付涵盖了软件交付端到端的整个周期，其覆盖面不仅仅包括编码，还包括：设计、测试、部署、运维、运营等等。如果你对自己的发展有更高的要求，那么你就应该学习一下持续交付的内容，它能让你看到更多与编码有关的其他东西，比如不同的编码方式等；也能让你站在更高的角度去看待自己的工作：研发效率的提高往往不是个人能力的提高，而是集体协同效率的提高。

你可以利用持续交付的工具或最佳实践，提高自己的工作效率和质量。

随着持续交付的流行，其配套的实践和工具也层出不穷。如果你玩过 ping-pong 式的结对编程（A 写测试，B 写实现，然后 B 写下一个测试，A 写重构和实现），你一定会觉得编程如此轻松有趣，而这种 TDD 的方式也很好的保证了代码质量。

你可以参与到持续交付实施中去，享受为其他程序员提供效率工具的挑战和乐趣。

试想一下，如果你是一个出租车司机，而你的乘客却是舒马赫（F1 世界冠军），此时你开车的压力会有多大。其实参与到持续交付的实施中也是一样，因为你正在用程序员的方式改造程序员的工作习惯，为程序员提供工具。虽然挑战和压力巨大，但这又是如此有趣，你将会站在另一个高度去看你曾经的工作。（转自Lomo）