持续集成（CI）
持续集成
早在20世纪80年代，微软office产品研发团队就使用一种开发实践，称为每日构建（daily build），也叫每晚构建（nightly build)。它指每天定时自动执行一次构建工作，也就是将当前版本控制系统中的源代码检出到一个构建环境中，对其进行编译、链接、打包。
而“持续集成”实践来自1996年Kent Beck提出的极限编程方法，并在《解析极限编程 — 拥抱变化》的第10章给出了一个简短说明：持续集成 – 每天多次集成和生成系统，每次都完成一个构建任务。
持续集成是一种质量反馈机制，其目的是”尽早发现代码中的质量问题“。持续构建的主要流程如下图所示。
持续集成工具
持续集成的工具众多，比如Jenkins、Travis CI、Team City、Gitlab CI等等，他们各自有各自的特点和优势。下面的这个文章介绍了目前主流的一些持续集成的工具和他们的比较：
英文原文： an-introduction-to-ci-with-comparison-of-17-major-ci-tools
研发团队可以根据自己的情况选择适合自己的持续集成工具，对于很多研发团队而言，尤其是Java体系的研发组织，Jenkins确实是一个不错的选择。Jenkins是一款历史悠久的免费持续集成工具，它使用人数众多，插件众多，是很多中小型研发团队的好选择。
持续交付与持续部署
考虑到技术变化的速度之快、变幻莫测，任何产品的竞争优势都在于它能够迅速地进入市场。一个组织的研发速度是它能够与其他竞争对手竞争、保持产品和服务质量或适应新规则的能力的关键因素，然而这个速度受到部署时间的限制。部署不会只在初始启动时发生一次。在教育工作者中有这样一种说法：没有一种课程计划能在与学生讲授后存活下来。同样，没有一款软件在首次发布时是完美的。唯一能保证软件优秀的方法就是必须对其进行不断地更新，而且要很快。
软件产品的长期生命周期包括对新思想的快速探索，对环境变化或用户问题的快速响应，以及在一定规模上提高开发人员的研发速度。从Eric Raymond的《大教堂和集市》到Eric Reis的《精益创业》，任何组织长期成功的关键都在于其能够将想法尽快付诸实施，并送到用户的手中，然后对他们的反馈做出快速反应。
Martin Fowler在他的《持续交付》(Continuous Delivery，又名CD)一书中指出：“对于任何软件工作来说，最大的风险是最终构建的是无用的东西。你越早、越频繁地将可工作的软件呈现在真正的用户面前，你就能越快地得到发现其真正价值的反馈。”
一致等到一项要花很长时间才能完成的工作全部完成之后再交付给用户，是一项高风险、高成本的事情，甚至可能会挫伤士气。软件研发团队应该努力尽早且经常发布，或者"启动并迭代"，以使团队能够快速看到他们工作的成果，并能够更快地适应不断变化的市场。
代码的价值不是在提交到代码仓库的时候体现的，而是在用户能够使用特性的时候体现的。尽量缩短"代码完成"与用户反馈之间的时间，可以将正在进行的工作的成本最小化。
持续交付和敏捷方法的一个核心原则是，随着时间的推移，小批量的变更会带来更高的质量；换句话说，越快越安全。乍一看，这对团队来说可能是非常有争议的，特别是在设置CD的先决条件（例如，持续集成和测试）还没有到位的情况下。因为对于所有团队来说，实现理想的CD可能需要一段时间，所以我们专注于开发在通往最终目标的过程中独立交付价值的各个方面。以下是其中一些:
- 敏捷性：频繁及小批量地发布。
- 自动化：减少或消除频繁发布的重复开销，特别是手动的部分。
- 隔离性：努力使用模块化架构来隔离变更并使故障排除更容易。
- 可靠性：测量关键运行状况指标，如崩溃或延迟，并不断改进它们。
- 数据驱动决策：使用A/B测试来确保软件质量。
- 分阶段推出：在将变更发布给所有用户之前，先将变更发布给少数用户。
持续交付（CD）
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。
它强调的是，不管怎么更新，软件是随时随地可以交付的。注意，持续交付在自动化测试和集成结束后，不一定会自动部署。如果有自动部署，则是持续部署的概念了。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
持续部署（CD）
持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
持续部署扩展了持续交付，因此，如果软件构建通过所有测试，则将自动部署。在这样的过程中，不需要人来决定何时以及什么生产。CI/CD系统的最后一步将自动部署成功退出交付管道的所有构建组件/软件包。