持续集成（Continuous Integration）指的是，频繁地（一天多次）将代码集成到主干。
在保证质量的前提，通过持续集成使产品进行快速的迭代。
它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称CI）。
持续交付（Continuous delivery）**在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
持续部署的前提是能自动化完成测试、构建、部署等步骤。
持续集成CI/CD工具:Jenkins、Travis CI、Drone、Wercker、Circle CI等等….
工具上的话，jenkins使用的较多，插件多、社区文化活跃。
常见组合:jenkins+svn+maven+ant、jenkins+GitLab
持续集成的核心价值在于：
- 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；
- 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能；
- 持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。
为啥需要持续集成CI/CD？
敏捷开发、快速交付是互联网行业的标准。一个产品、一个项目团队，通过高效的敏捷开发，以及快速交付产品的流程使其能从软件行业中脱颖而出。说白了就是为了应对快速变化需求的一个解决方案或者手段。
解放运维劳动力，提高效率，减少因发布、部署、交付更新带来的失误。
随着软件开发复杂度的不断提高，团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来，敏捷（Agile） 在软件工程领域越来越红火，如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。
持续集成正是针对这一类问题的一种软件开发实践。它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。
持续集成CI/CD的好处
快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的大致流程:
编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署
持续集成的原则
业界普遍认同的持续集成的原则包括：
- 需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 git、svn 等；
- 开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；
- 需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；
- 必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。
持续集成系统的组成
由此可见，一个完整的构建系统必须包括：
- 一个自动构建过程，包括自动编译、分发、部署和测试等。
- 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
- 一个持续集成服务器。
在实施CI/CD对整个团队文化的影响
CICD是一个流程上的实践，我们把代码开发、到代码部署、到最后的交付，进行持续地迭代和交付，在这个过程中对原来的团队产生的影响是这样的：开发不再只关注他在开发这部分的实现，他需要保证从代码开发实现、到单测、到测试、到构建部署，到最后的分发发布，这样整个流程的覆盖。按照我的理解，CICD对整个团队文化的影响是，每个人对产品研发的整个流程都要全部参与进去，不再是只局限在自己的角色上。比如我是一个开发，我只做实现，我不再关注部署和测试；或者我是一个测试，我不关注开发实现，不关注部署，我只关注执行；或者我是一个运维，我对前面的所有流程都不了解，我只执行最后的运维步骤，而CICD就是把整个团队有效地集成在一起，通过一个流程持续地迭代发布验证，这样的话，整个团队就能更高效地展开合作。
多分支、多版本实施CI/CD的建议
我们目前的确也遇到了多分支并行的情况，也就是说我们需要对不同的业务场景做不同的版本管理。在这种情况下，我们依然可以做CI的实施，但是要经过专门的设计，在每个分支所运行的软件，它的版本管理需要做统一的管理，比如需要规划每个分支的依赖是什么样的，要把整个路径都管理起来。如果没有这样的管理，从构建到部署到测试都是混乱的。在版本管理的基础上，我们还要把代码和测试有效地集成起来，也就是说，不光是代码到测试，是代码到配置、到测试、到部署，都要有效地集成起来。一份代码在这个分支上，它对应的配置在哪里，是什么版本，在这个分支上测试的版本在哪里，都需要管理起来；在这个分支上，代码部署的版本依赖也需要统一的管理。如果我们没有做好这些基础设施，是没有办法做CICD实施的。当我们把这些整理清楚之后，再针对每个分支做整体的实施，通过版本管理去理清楚我们实施的部署构建，到底依赖圈是什么样的，这样就可以做一个正确的实施。