持续集成 vs. 持续交付 vs. 持续部署
在现代开发实践的讨论中，CI和CD被视为两个重要的缩略词。持续集成（CI）旨在简化发布流程。然而，在某些情况下 CD 可能代表持续交付或持续部署。尽管两者具有许多相似之处但在某些情况下可能会导致对业务的重大影响
我们将在本文中看到这三种实践的含义以及使用它们需要什么条件。
持续集成，持续交付和持续部署之间有什么区别？
持续集成
采用持续集成策略的开发人员会最大限度地将提交的数据变更整合到主版本库中。他们将建立构建流程，并通过自动化测试流程来验证每个提交的质量与稳定性。采用这种策略后, 您将避免通常在一般而言, 在等到正式发布时才进行版本库合并所导致的技术挑战与混乱情况, 也就是我们常说的"集成地狱"。
持续集成体系特别重视测试自动化工作，在将新的提交整合到主分支的过程中会自动检查应用程序是否受到影响。
持续交付
持续交付可被视为持续集成的一个方面,其主要目标在于让您能够通过可持续的方式迅速发布新的变更。这不仅包括实施自动化测试,还涉及支持自动化的发布流程,您还可以通过点击按钮来快速部署应用程序
从理论上分析, 采用持续交付策略, 您可以选择每天、每周或每两周等不同频率来安排发布周期, 这取决于您的业务需求. 为了充分利用持续交付带来的好处, 建议您尽快投入生产环境以发挥其优势. 正确的小型版本推送有助于确保在出现问题时能够快速定位并修复问题.
持续部署
相较于持续性的交付，“持续性的 部署将更加深入和全面”。在采用这种方法的情况下，在生产管道的所有环节进行的所有变更都将得到通知并立即执行。无需人工干预，在任何情况下只有经过严格测试才能防止新的变更从设计状态直接进入实际应用环境。
持续集成能够有效促进与客户的高效反馈机制，并且无需固定发布周期就可以显著减少工作压力和焦虑感。开发人员能够专注于构建软件系统，并在完成几分钟后就能快速投入生产中。
这些实践如何相互关联？
概述而言，在软件开发过程中，持续集成被视为一个关键环节，并被认为是持续交付与持续部署这两个概念的重要组成部分。除了自动发布之外，在功能上它与持续交付具有相同的特性
概述而言，在软件开发过程中，持续集成被视为一个关键环节，并被认为是持续交付与持续部署这两个概念的重要组成部分。除了自动发布之外，在功能上它与持续交付具有相同的特性
每种实践有什么好处？
我们已经阐述了持续集成、持续交付与持续部署之间的区别与联系，并提出了深入探讨您为何选择采用这些实践的新建议。然而，在深入分析您为何选择采用这些实践方面仍有许多问题亟待解决。尽管实施每项实践都存在一定的成本与挑战（其实施成本显著高于其带来的益处），但目前的研究进展仍然有限。
您需要什么成本？
您的团队需要为每个新功能，改进或bug修复编写自动化测试。
您需要一个持续集成服务器，它可以监视主仓库并为每个推送的新的提交自动运行测试。
开发人员需要进可能多地合并他们的更改，至少每天一次。
您获得了什么益处？
通过使用自动化工具进行回归测试时发现了bug，在生产环境中出现的bug数量会减少。
经过对所有集成问题的及时修复后, 构建版本变得更加简便易行。
降低了上下文切换频率；开发人员一旦中断构建过程会立即收到警报提示, 并能在转移其他任务前及时修复。
测试成本显著降低 - 您的CI服务器可以在短短几秒钟内处理数百次测试任务。
您的QA团队节省了时间用于执行测试工作的同时, 可将精力集中在提升质量文化的重要方面。
持续交付
您需要什么成本？
您的持续集成项目必须建立在扎实的基础上，并要求测试套件能够充分覆盖充足的代码量。
部署过程必须实现自动化；虽然目前触发器操作仍需人工干预（即手动设置），但一旦启动部署流程，则无需后续人工操作。
您的团队很可能需要采用功能标记机制；因为如果存在未完善的功能，则可能导致生产环境中现有客户的正常运作受到影响。
您获得了什么益处？
软件部署过程已无复杂性可言,您的团队无需投入大量时间准备发布。
您可采取定期发布的方式,从而提升反馈机制的响应速度。
微小变化带来的决策压力显著降低,这将促进组织能够快速迭代和优化。
持续部署
您需要什么成本？
您的测试文化需要处于最佳状态。测试套件的质量将决定您的版本的质量。
您的文档需要跟上部署的步伐。
功能flags成为发布重大更改过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。
您获得了什么益处？
您可以在更快速度上完成开发工作，在无需中断开发流程的情况下实现版本更新。每次代码更改都会自动触发部署管道的建立。
在分批次执行代码更改时，在出现问题的情况下其版本风险较小且更容易解决问题。
客户每天都可以随时掌握持续改进的成果以及质量提升的具体情况，并无需定期检查更新情况。
与持续集成相关的主要成本之一是CI服务器的安装和维护费用。然而，借助Bitbucket Pipelines等云服务解决方案能够显著降低了采用这些实践所带来的总成本，并且为每个Bitbucket仓库增添了自动化的部署功能。只需在项目根目录中添加配置文件即可创建一个连续的部署管道，该管道能够将所有变更自动推送到主分支。
从持续集成到持续部署
个人在未有客户的新项目启动时，在没有用户的情况下初次部署时，可能会遇到诸多挑战与困难。采用自动化部署策略后，并非立即就能完成任务，在Alpha版本发布至无客户的生产环境中进行初步测试后，在构建应用程序的过程中逐步增加代码覆盖率是一个重要步骤。这有助于加强测试文化，并确保整个持续集成流程已达到高度优化的状态。当计划逐步引入用户时，在构建应用程序的过程中逐步增加代码覆盖率是一个重要步骤。
然而，在您的现有应用已有客户群体的情况下，则应当逐步推行持续集成与持续交付工作。首先应致力于实现单元测试流程的自动化操作，并无需深入处理复杂端到端测试环节。另一方面，请尽快推进自动化部署工作，并将逐步实施从开发环境中直接部署至生产环境的过程方案。这一策略的主要优势在于使您可以集中精力建设优化方案而非频繁协调版本发布事宜
当您每天发布软件时
作者：Sven Pittinger
翻译：毛哥
日期：2019年6月23
原文：https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment