以下源引于网络，非本人原创，纯粹是为了方便理解和回顾
持续集成
强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
确保新增的代码能够与原先代码正确的集成
- 开发人员提交代码到 Source Repository （源代码仓库），并通过 git hook 等
- 触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果 的流程，
- 向开发人员反馈结果的 report
好处：
- 易于定位错误：每一次的代码集成都需要执行相关的测试工作，持续集成频繁的集成次数天然的将复杂的代码逻辑切割为了小块，也就使得每一次测试中遇到的错误能够更加容易的被定位；
- 易于控制开发流程：更为细致的工作提交也就意味着更容易判断当前的工作进度，这对于管理者规划开发流程而言提供了一个有效的参考，同时也为开发人员省下了汇报工作的时间；
- 易于CodeReview：对于大块工作的切分自然也有助于做 CodeReview；
- 易于减少不必要的工作：build 以及 test 过程的自动化可以为你节约一大票的时间，从而投入到有价值的工作中去。
持续交付
强调客户功能交付，使得软件在较短的循环中可靠的发布的软件工程方法。在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
与 持续集成 相比较，持续交付 添加了 Test -> Staging（模拟环境） -> Production 的流程，也就是为新增的代码添加了一个保证： 确保新增的代码在生产环境中是可用的 。
从开发到运维的工作能够稳定地快速流动，确保不会造成生产环境的混乱或客户服务的中断。需要降低在生产环境中部署和发布变更的风险。
在这一增加的流程中，Test 环节不仅仅包含基本的单元测试，还需要延伸到更为复杂的功能测试以及集成测试等。在这里，Staging 指的是 类生产环境 ，其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。流程中每一个环节的执行结果都会对开发人员进行反馈，每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后，将由相关人员对其进行 手动部署到生产环境。
持续部署
强调自动化，则是在持续交付的基础上，把部署到生产环境的过程自动化
通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过 automated deployment 的手段，对新的软件功能进行集成。
强调 Production 的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。
总结
对于 持续集成、 持续交付 和 持续部署 三者的理解是：
- 持续集成 是三者中最简单的，同时也是开销最低的。由于不需要类生产环境的配合，测试环境也可以仅支持单元测试的执行，使得持续集成的实现是最为便宜的。考虑到现实开发过程的种种限制，向资源与成本做妥协，舍弃持续交付或者持续部署这样看起来很美的方法，退而转向持续集成也是很合理的选择；
- 持续交付 面向开发初期或者软件稳定性或者安全性要求较高的领域，新增代码提交、编译、测试等一系列环节均可以通过自动化工具完成，很好的节约了人力资源的同时，还对新增代码的功能进行了有效的保障。在手动执行的部署环节，还可以添加在执行完毕标准测试之外的可能需求，以保证发布功能的可靠；
- 持续部署 面向稳定的发布上线后的功能更新。自动的，无需人工干预的部署可以保证新增功能第一时间被发布到生产环境中，确保其尽快的被用户所使用。其与持续交付相比，就在于其功能可靠性与功能及时性的侧重不同。
阮一峰：http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
DevOps 更偏向于一种文化的构建，在 DevOps 文化指导下，团队中将包含了具有不同技能的人员（开发、测试等），并通过自动化测试与发布的手段，更快、更高质量的生产软件。
handoff-传递，release-发布，operate-运营
