如何理解持续集成、持续交付、持续部署？
身为没有技术背景的产品人员，靠自己搜索信息深刻理解这三个概念实在过于痛苦（相反，产品人员对精益是很容易深刻理解且高度认同的，因为越来越明白再好的产品人员、再好的用研意识与方法都无法保证需求的正确性，前期过度的产品设计是浪费的），所以来知乎上求助一下技术达人有没有现成的总结。
如何分辨与理解这三个概念？
你所在的技术团队是否认同与实践推广？在实践推广的过程中总结出了什么心得？
这类概念是否有必要向产品同事、老板普及推广？在普及推广中有过什么事情发生？
集成是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；
部署是代码尽快向可运行的开发/测试节交付，以便尽早测试；
交付是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题。
如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。
而所谓的持续，就是说每完成一个完整的部分，就向下个环节交付，发现问题可以马上调整。是的问题不会放大到其他部分和后面的环节。
这种做法的核心思想在于：既然事实上难以做到事先完全了解完整的、正确的需求，那么就干脆一小块一小块的做，并且加快交付的速度和频率，使得交付物尽早在下个环节得到验证。早发现问题早返工。
举个例子，你家装修厨房，其中一项是铺地砖，边角地砖要切割大小。如果一次全切割完再铺上去，发现尺寸有误的话浪费和返工时间就大了，不如切一块铺一块。这就是持续集成。
装修厨房有很多部分，每个部分都有检测手段，如地砖铺完了要测试漏水与否，线路铺完了要通电测试电路通顺，水管装好了也要测试冷水热水。如果全部装完了再测，出现问题可能会互相影响，比如电路不行可能要把地砖给挖开……。那么每完成一部分就测试，这是持续部署。
全部装修完了，你去验收，发现地砖颜色不合意，水池太小，灶台位置不对，返工吗？所以不如没完成一部分，你就去用一下试用验收，这就是持续交付。
——————–
补充：从敏捷思想中提出的这三个观点，还强调一件事：通过技术手段自动化这三个工作。加快交付速度。
最近看了一篇文章 The Product Managers’ Guide to Continuous Delivery and DevOps 文中对「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」这三个概念有很详细的解释。这里借用文中的插图，说一下我对这三个概念的理解。
持续集成
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（
production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续
手动部署到生产环境中。
持续部署
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工，而持续集成、持续交付、持续部署恰恰可以早发现早解决，从而可以避免这个问题。
- 代码越早push出去，用户能越早用到，快就是商业价值；
- 用户越早用到就越早反馈，团队越早得到反馈，好坏都是有价值的输入；
- 用户不反馈，说明我们做了用户不想要的东西（通过用例跟踪）或者marketing没做好，能帮助产品市场人员调整策略；
- 代码库存越是积压，就越得不到生产检验，积压越多，代码间交叉感染的概率越大，下个release的复杂度和风险越高；
- 代码库存越多，workflow的包袱越重，管理成本越大，说敏捷越可笑。
流水不腐，户枢不蠹。
职业生涯没有被要求过要区分这三个概念 …
其实应该是四个词：持续集成、持续部署、持续交付、持续发布。
咱们把这几个词拆解一下：
持续 (Continuous)：不断的获取反馈，响应反馈。
集成 (Integration)：编译、测试、打包；
部署 (Deployment)：应用组件或基本设施的代码或配置变更在产品环境生效称为“部署”；
发布 (Release)：具有业务影响的功能变化对最终用户可见称为“发布”。
交付 (Delivery)：可以理解为从 Deployment 到 Release 之间的阶段，更多的强调的是一种能力。开发有能力频繁的部署，业务有能力随时发布。
如何从部署到发布？
使用 特性开关（Feature Toggle） 或 灰度发布（Dark Launching） 等技巧可以使我们更加频繁地部署变更到产品环境但并不发布功能。
频繁部署可以有效降低变更带来的风险,同时业务负责人仍然能保持何时向最终用户发布功能的控制。
资料引用：
1、如何分辨与理解这三个概念？
1）持续集成：
集成，就是在一起：代码commit是集成（代码在一起），编译是集成（逻辑在一起）；
部署是集成（部署包跟环境在一起），测试是集成（功能在一起），灰度是集成（系统在一起）
不断的做集成和集成结果的修正，就是持续集成；
2）持续交付：
交付：就是将最终的产品发布到线上环境，给用户使用。
持续交付描述的软件开发，是从原始需求识别到最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺畅流动，能够以较短地周期完成需求的小粒度频繁交付。频繁的交付周期带来了 更迅速的对软件的反馈，并且在这个过程中，各个角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
3）持续部署
持续部署：就是持续的将需求部署到目标环境上。
2、你所在的技术团队是否认同与实践推广？在实践推广的过程中总结出了什么心得？
我们团队一直在做持续交付，半年做下来效果很好，每天做自动化构建打包、部署、验收，每天都会有完成的内容，每个迭代交付的故事点趋势是稳定向上发展的。
在推广的过程中，需要强调单元测试、功能测试等自动化测试的重要性，只有做好自动化测试，才能建立好保护机制，快速给予反馈，快速修复问题。另外自动化的工具也是必须要做的，现在市面上有不少类似的工具，国外的有Amazon Web Services (AWS)，国内的有CRP持续交付平台持续交付平台。相对来说，国内的要更贴近国内开发者，amazon的学习成本比较高。我们团队用的是CRP持续交付平台，免费，代码托管、自动化构建、部署等都做的比较完整。
3、这类概念是否有必要向产品同事、老板普及推广？在普及推广中有过什么事情发生
这块内容是需要不断的和同事和老板推广的，因为持续交付最终的目的是快速迭代、快速反馈，不断的改进。这样可以帮助老板和产品提高交付能力的，也可以帮助研发团队提高效率。
推广还是会有困难的，国内能做到持续交付的团队并不算多，很多都知道好处，但是单元测试和自动化功能测试等内容会需要开发投入不少精力，首先还是需要说服研发的负责人赞同你的观念哦。
刚好最近在看相关资料，分享一下
持续集成
看敏捷教父对持续集成的定义
Martin Fowler：
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
看图
图片出处：google.com 的页面
持续交付、持续部署
将持续集成扩充到部署到生产环境就是持续交付和持续部署的概念，二者的区别，看图
图片出处：Crisp’s Blog
就是在 任何时候，对外都能提供可以分发、安装、使用的新版本
这要求：
1、系统的总体框架、主干 成熟、稳定、简洁
2、更新、发布、安装、运行、重置 简单方便
3、任何改进、改动都在独立分支进行，并能快速合并回主版本
4、重新生成发布包 能随时、自动、快速进行
举一个具体例子：
如果必须有客户端，必须是绿色的，而且能自动根据后台设置进行自我更新
与后台的交互通过 服务端的IP+端口 进行访问，协议最好是http(s)
如果涉及数据库，不能直接连接，而是通过应用服务器（web app）中转
如果不能做到自动化，持续集成最好还是一个想法，不然会把团队拖死。