持续集成&持续交付（CI&CD）

概念

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题。
具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。

持续集成（CI：Continuous Integration）

CI/CD 中的“CI”始终指持续集成，它属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。
持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。

持续交付（CD：Continuous Delivery）

CI/CD 中的“CD”指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会单独使用，用于说明自动化程度。
持续交付通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库，然后由运维团队将其部署到实时生产环境中。旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。
持续部署（另一种“CD”）指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。持续部署以持续交付的优势为根基，实现了管道后续阶段的自动化。

产生与发展

软件工程方法编年史

软件工程发展概述

• 瀑布软件开发方式
  
  特点：简单，分阶段，阶段间存在因果关系，各个阶段完成后都有评审，允许反馈，不支持用户参与，要求预先确定需求。
  适用于需求易于完善定义且不易变更的软件系统
• 敏捷软件开发方式
  
  特点：作为整体工作；短迭代周期；每次迭代交付一些成果；关注业务优先级； 检查与调整。
  理念：个人与交互重于开发过程与工具；可用的软件重于复杂的文档；寻求客户的合作重于对合同的谈判；对变化响应重于始终遵循固定的计划。
• Devops运动
  
  特点：倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控的IT组织管理的发展趋势。
  优势与劣势：解放开发、运维生产力（技术要求高）；促进组织结构松散化（边界模糊，无法专注）；使运维更贴近业务（立场不同，无法达成决策）；应对变更能力强，快速迭代（管理死角，规模扩展性不好）
  理念：一切皆代码，自动化一切，部署流水线尽早反馈。
• 云原生
  软件的影响力正在日益凸显，它不但会影响用户与企业间的互动方式，还会影响企业为保持市场竞争力而做出的创新之举。因此，应用的快速开发和交付已成为数字化企业必须要满足的一项新需求。
  为了满足这一需求，企业必须采用云原生方法来开发应用，以提高速度、增加灵活性、改善质量并降低风险。
  ** 云原生内容依赖关系
  
  首先，为了抓住商业机会，业务需要快速迭代，不断试错，因此，企业需要依赖拥有持续交付的能力，这些不仅包括技术需求还包括产品的需求，如何能拥有持续交付的能力，大而全的架构因为效率低下，显然是不合适的。于是演变出微服务架构来满足需求，通过把系统划分出一个个独立的个体，每个个体服务的设计依赖需要通过12要素的原则来规范完成。同样，如果系统被分成了几十个甚至几百个服务组件，则需要借助DevOps才能很好地满足业务协作和发布等流程。最后，DevOps的有效实施需要依赖一定的土壤，即敏捷的基础设施服务，现实只有云计算的模式才能满足整体要求。通过上述梳理，我们总结出面向云原生应用的3个不同层次的特点。
  高可用设计（Design for Availability），依据应用业务需求，高可用分为不同级别，比如不同区域、不同机房（跨城或同城）、不同机柜、不同服务器和不同进程的高可用，云原生应用应该根据业务的可用性要求设计不同级别的架构支持。
  可扩展设计（Design for Scale），所有应用的设计是无状态的，使得业务天生具有扩展性，在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容，满足业务需求。
  快速失败设计（Design for Failure），即包括系统间依赖的调用随时可能会失败，也包括硬件基础设施服务随时可能宕机，还有后端有状态服务的系统能力可能有瓶颈，总之在发生异常时能够快速失败，然后快速恢复，以保证业务永远在线，不能让业务半死不活地僵持着。
  ** 微服务结构之12要素
  
  特点：通过强化详细配置和规范，基于“约定优于配置”（convention over configuration）的原则，特别在大规模的软件生产实践中，这些约定非常重要，从无状态共享到水平扩展的过程，从松耦合架构关系到部署环境。基于12要素的上下文关联，软件生产就变成了一个个单一的部署单元；多个联合部署的单元组成一个应用，多个应用之间的关系就可以组成一个复杂的分布式系统应用。
  参考：https://12factor.net/zh_cn/
  ** 实现云原生成功的实践步骤
  1.采用充分利用 DevOps 所需的技术和协作流程
  2.借助经过优化的单体式应用，提高现有应用的运行速度
  3.构建可按需提供的自助式基础架构
  4.实现 IT 自动化，加速交付应用
  5.实施持续交付和高级部署技术
  6.推动变革，采用模块化程度更高的架构

流程与方法论

开发流程

图片来源（https://www.sonatype.com/products-overview）

持续集成和部署主要参与者

• 源代码库：负责存储源代码，常用的有Git和SVN
• 持续集成与部署工具：负责自动编译和打包以及把可运行程序存储到可运行库。比较流行的有Jenkins，GitLab，Travis CI，CircleCI 等.
• 库管理器(Repository Manager)：也就是图中的Repository，我们又叫运行库，负责管理程序组件。最常用的是Nexus。它是一个私有库，它的作用是管理程序组件。
  持续集成系统的组成:
  1.一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库.
  2.一个自动构建过程，包括自动编译、分发、部署和测试等
  3.一个持续集成服务器,负责自动编译和打包以及把可运行程序存储到可运行库.
  持续部署步骤：
  1.下载源码：从源代码库中下载源代码(Gitlab)
  2.编译代码：编译语言都需要有这一步
  3.测试：对程序进行测试
  4.生成镜像：这里包含两个步骤，一个是创建镜像，另一个是存储镜像到镜像库(Docker hub)
  5.部署镜像：把生成的镜像部署到k8s

工具链

• Gitlab
  开源的版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。
  与Github类似，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，易于浏览提交过的版本并提供一个文件历史库。成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
• Nexus
  管理第三方库：第三方公共库管理不方便，建立一个私有管理库，来集中统一管理各种第三方软件。例如它既可以做为Maven库（Java），也可以做为镜像库（Docker），还可以做为NPM库（JavaScript），来保证公司软件的规范性。
  管理内部程序的交付：所有公司在各种环境（例如DEV，QA，UAT， PROD）发布的程序都由它来管理，并赋予统一的版本号，这样任何交付都有据可查，便利于程序回滚
• Jenkins
  Jenkins是一款开源 CI&CD 软件，用于自动化各种任务，包括构建、测试和部署软件。使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上
  java语言开发，用于监控持续重复的工作，包括：持续的软件版本发布/测试项目，监控外部调用执行的工作。
  Jenkins 支持各种运行方式，可通过系统包、Docker 或者通过一个独立的 Java 程序。
  流水线：流水线是用户定义的一个CD流水线模型 。流水线的代码定义了整个的构建过程, 他通常包括构建, 测试和交付应用程序的阶段 。另外 ， pipeline 块是 声明式流水线语法的关键部分.Jenkins 流水线 是一套插件，它支持实现和集成 continuous delivery pipelines 到Jenkins。对Jenkins 流水线的定义被写在一个文本文件中 (称为 Jenkinsfile)，该文件可以被提交到项目的源代码的控制仓库， 这是"流水线即代码"的基础; 将CD 流水线作为应用程序的一部分，像其他代码一样进行版本化和审查。
  Blue Ocean:Blue Ocean 重新思考Jenkins的用户体验，从头开始设计Jenkins Pipeline, 但仍然与自由式作业兼容，Blue Ocean减少了混乱而且进一步明确了团队中每个成员 Blue Ocean 的主要特性包括：持续交付(CD)Pipeline的 复杂可视化;Pipeline 编辑器;个性化;在需要干预和/或出现问题时 精确定位;本地集成分支和合并请求.
• Docker
  软件开发最大的麻烦事之一就是环境配置，操作系统的设置、各种库和组件的安装带来的兼容性，复杂性，重复性给项目实施带来了巨大的消耗。虚拟机就是一种带环境安装的解决方案，但资源占用多，冗余步骤多，启动慢。这样就诞生了Linux容器技术（由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境），由于容器是进程级别的，具有启动快，资源占用少，体积小的优势，类似于轻量级的虚拟机，能够提供虚拟化的环境，成本开销小很多。Docker属于Linux容器的一种封装，提供简单易用的容器使用接口，是目前最流行的Linux容器解决方案。
  Docker 项目通过“容器镜像”，解决了应用打包这个根本性难题。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程.
  发展现状
  容器技术圈子在短短几年里发生了很多变数，但很多事情其实也都在情理之中。就像 Docker 这样一家创业公司，在通过开源社区的运作取得了巨大的成功之后，就不得不面对来自整个云计算产业的竞争和围剿。而这个产业的垄断特性，对于 Docker 这样的技术型创业公司其实天生就不友好。
  在这种局势下，接受微软的天价收购，在大多数人看来都是一个非常明智和实际的选择。可是 Solomon Hykes 却多少带有一些理想主义的影子，既然不甘于“寄人篱下”，那他就必须带领 Docker 公司去对抗来自整个云计算产业的压力。只不过，Docker 公司最后选择的对抗方式，是将开源项目与商业产品紧密绑定，打造了一个极端封闭的技术生态。而这，其实违背了 Docker 项目与开发者保持亲密关系的初衷。
  相比之下，Kubernetes 社区，正是以一种更加温和的方式，承接了 Docker 项目的未尽事业，即：以开发者为核心，构建一个相对民主和开放的容器生态。
  参考：https://ruanyifeng.com/blog/2018/02/docker-tutorial.html
• Kubernetes
  过去很多的集群管理项目（比如 Yarn、Mesos，以及 Swarm）所擅长的，都是把一个容器，按照某种规则，放置在某个最佳节点上运行起来。这种功能，我们称为“调度”。而 Kubernetes 项目所擅长的，是按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系。这种功能，就是我们经常听到的一个概念：编排。所以说，Kubernetes 项目的本质，是为用户提供一个具有普遍意义的容器编排工具。不过，更重要的是，Kubernetes 项目为用户提供的不仅限于一个工具。它真正的价值，乃在于提供了一套基于容器构建分布式系统的基础依赖。
  Kubernetes 项目就没有像同时期的各种“容器云”项目那样，把 Docker 作为整个架构的核心，而仅仅把它作为最底层的一个容器运行时实现。
  Kubernetes 项目最主要的设计思想是，从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地
  Kubernetes 项目从一开始就比较幸运地站上了一个他人难以企及的高度：在它的成长阶段，这个项目每一个核心特性的提出，几乎都脱胎于 Google Borg/Omega 系统的设计与经验。更重要的是，这些特性在开源社区落地的过程中，又在整个社区的合力之下得到了极大的改进，修复了很多当年遗留在 Borg 体系中的缺陷和问题。
  所以，尽管在发布之初被批评是“曲高和寡”，但是在逐渐觉察到 Docker 技术栈的“稚嫩”和 Mesos 社区的“老迈”之后，这个社区很快就明白了：Kubernetes 项目在 Borg 体系的指导下，体现出了一种独有的“先进性”与“完备性”，而这些特质才是一个基础设施领域开源项目赖以生存的核心价值。

参考：
https://www.cnblogs.com/163yun/p/8889083.html
https://www.redhat.com/zh/topics
https://12factor.net/zh_cn/
https://time.geekbang.org/column/article/23132
《持续交付2.0 业务引领的DevOps精要》