一、概述
1.DevOps
DevOps 就是开发（Development）、测试（QA）、运维（Operations）这三个领域的合并。
为什么要合并这三个领域？主要是开发和运维的脱节。
DevOps是一种思想、一组最佳实践、以及一种文化。DevOps落地实施，从组织架构、设计人员、流程、人员分工、人员技能到工具，变化很大，要求很高，完全颠覆了现有的开发运维模式，建设风险很高。
DevOps落地困境包括：
- 涉及的部门多（开发中心、质量控制部门、生产运行部门）；
- 流程改造复杂；
- 责任边界需要重新划分；
- 自动化是核心问题。
如下图，传统开发和运维之间存在一堵墙，开发人员想改变而运维人员想要稳定。另外，传统开发工具与运维工具也存在一堵墙，并没有打通成为一条工具链。
2.CI/CD
CI CD一般包含三个概念：持续集成（Continuous Integration ，CI），持续交付（Continuous Delivery），持续部署（Continuous Deploy）。
持续集成 在传统软件开发过程中，集成通常发生在每个人都完成了各自的工作之后，所谓集成，可以理解为团队里的大家完成自己负责的模块后，将各个子模块集成为一个可以完成整体功能的完整模块。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。
为了实现持续集成，我们每个人都要单元测试（unit test），保证各个子模块的正常工作。
持续交付 持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。我们把代码部署到测试环境，预发布环境等等类生产环境成为交付。
持续部署 如果真的想获得持续交付的好处，应该尽早部署到生产环境，以确保可以小批次发布，在发生问题时可以轻松排除故障。于是有了持续部署。
我们通常将这个在不同环境发布和测试的过程叫做部署流水线
持续部署是在持续交付的基础上，把部署到生产环境的过程自动化。
3.CICD与DevOps
DevOps（Development & Operations，开发和运维）是09年提出来的概念，但一直没有太火。直到14年，容器与微服务架构的提出，DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。
对于DevOps，微服务不是必须的，但微服务为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。所以，也有人称微服务是DevOps架构。
DevOps与下面提到的CI、CD不同，DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。DevOps的概念似乎与持续交付的概念有些类似，两者均旨在促进开发与运维之间的协作，但是实际上两者差别很大：DevOps 更偏向于一种文化的构建，在DevOps文化指导下，团队中将包含了具有不同技能的人员（开发、测试等)，并通过自动化测试与发布的手段，更快、更高质量的生产软件。
CI、CD、DevOps 关系
CICD更关注的是整个开发，测试，部署的自动化的过程，当我们在本地单元测试通过后，我们提交到git上，触发相应的webhook或者类似的东西进行代码的构建，并打包部署到相应的机器上，自动化的完成这整个过程。
而DevOps更关注的是打通用户、PMO、需求、设计、开发（Dev）、测试、运维（Ops）等各上下游部门或不同角色；打通业务、架构、代码、测试、部署、监控、安全、性能等各领域工具链；尤其是打通开发与运维之间的gap，因为两者实际上存在着很多的冲突。DevOps是基于CICD的，自动化的流程是基础，DevOps是一个项目由idea到实际稳定运行的产品的一个最佳实践。
DevOps是CICD思想的延伸，CICD是DevOps的基础核心，如果没有CICD自动化的工具和流程，DevOps是没有意义的。
二、基础
1.DevOps
DevOps 是 Development（开发）和 Operations（运维）的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合，以期打破传统开发和运营之间的壁垒和鸿沟；
DevOps 是一种重视软件开发人员（Dev）和IT运维技术人员（Ops）之间沟通合作的文化、运动或惯例，通过自动化软件交付和架构变更的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠；具体来说，就是在软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品；
也就是说 DevOps 是一组过程和方法的统称，并不指代某一特定的软件工具或软件工具组合；各种工具软件或软件组合可以实现 DevOps 的概念方法，其本质是一整套的方法论，而不是指某种或某些工具集合，与软件开发中设计到的 OOP、AOP、IOC（或DI）等类似，是一种理论或过程或方法的抽象或代称。
2.CI
CI 的英文名称是 Continuous Integration，中文翻译为持续集成；CI 中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证；
持续集成 CI 是在源代码变更后自动检测、拉取、构建和进行单元测试的过程，持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用；CI 的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。
3.CD
CD 对应多个英文名称，持续交付 Continuous Delivery 和持续部署 Continuous Deployment，以下分别介绍。
持续交付（Continuous Delivery）
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库；为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道，持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化；在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。
持续部署（Continuous Deployment）
对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署；作为持续交付（自动将生产就绪型构建版本发布到代码存储库）的延伸，持续部署可以自动将应用发布到生产环境；
持续交付意味着所有的变更都可以被部署到生产环境中，持续部署意味着所有的变更都会被自动部署到生产环境中，但是出于业务考虑可以选择不部署；如果要实施持续部署，必须先实施持续交付；
持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署；持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段
