假如把开发工作流程分为以下几个阶段：
编码->构建->集成->测试->交付->部署
正如你在上图中看到，持续集成（ContinuousIntegration）、**持续交付（ContinuousDelivery）和持续部署（ContinuousDeployment）**有着不同的软件自动化交付周期。
持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程（XP），是XP最初的12种实践之一。
(1)CI需要具备这些：
(2)持续集成的优点
(3)持续集成，该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统，关键在于团队运行的基础设施，团队对持续集成系统的资源投入力度。
对比一下私有部署和托管型持续集成系统，或许能帮助你更好地做出选择。
整体而言，Jenkins过去一直是大部分公司的选择，但这个现象正在发生改变，随着公有云服务、Docker，SaaS的普及，越来越多的企业开始选择HostedCI，也就是托管型持续集成系统。
另外，在选择合适的持续集成服务时，还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
选择持续集成系统只是持续集成应用的其中一步，还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成，可为持续交付与持续部署打好坚实基础。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-likeenvironments）中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。
试想想，如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中进行更多的自动化测试。如果代码没有问题，可以继续手动部署到生产环境中。当然，持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。
(1)持续交付的好处
持续交付和持续集成的优点非常相似：
持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“ContinuousRelease”。
(1)为什么说持续部署是理想的工作流程？
“开发人员提交代码，持续集成服务器获取代码，执行单元测试，根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，进行整体验收测试，如果测试通过，自动部署到产品环境，全程自动化高效运转。”
实际上，产品在从需求到部署的过程中，会经历若干种不同的环境，例如QA环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，产品在不同环境中的具体部署，状况是比较非常复杂的，从头到尾地全自动持续部署的确困难。那么，如果能做到持续交付，保证代码在模拟环境没问题，也许团队成员做到真正的心理有数。
(2)持续部署的优点
持续部署主要好处是，可以相对独立地部署新的功能，并能快速地收集真实用户的反馈。
“Youbuildit,yourunit”，这是Amazon一年可以完成5000万次部署，平均每个工程师每天部署超过50次的核心秘籍。
持续集成（ContinuousIntegration）、持续交付（ContinuousDelivery）和持续部署（ContinuousDeployment）提供了一个优秀的DevOps环境，对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。