透过CICD工具链演进看持续交付

一、基本概述

持续交付的核心是快速高质量地交付价值，给与开发人员最大自由度，负责开发和运维全部过程。在监控、故障防控工具、功能开关的配合下，可以在保障用户体验和快速交付价值之间找到平衡点。
建设持续交付能力，首先要做到两个解耦：
1）需求之间的解耦，让各个需求的开发和发布能够独立进行；
2）部署和发布之间的解耦，让部署的动作更加灵活，发布能够随需进行。

而为了实现这两个解耦，会面临诸多挑战，这也是诸多工具诞生的原因，下面围绕CICD工具来讲解持续交付的演进。

二、持续交付模型

一般来讲应用程序交付包括如下图所示的几个阶段:

1. 计划阶段: 此阶段主要是项目经理或产品经理从用户处获取应用程序的相关信息，从而制定开发计划，来对后期开发进行指导。
2. 编码阶段: 这个阶段主要是开发人员通过IDE来进行代码开发，开发人员借助于安装在IDE内的一些插件，来编写符合公司编码规范和安全需求的代码。
3. 构建阶段: 这个阶段是指开发人员在本地完成代码开发，并将代码提交到源码控制工具(比如git)，此时会触发CI构建流程，进行代码扫描，编译，单元测试及覆盖率测试等工作。如果流程是成功的，那么代码就会被合入主干分支(合并可以是手动，也可以是自动，这取决于项目的开发模式与规定)。而一旦某个环节出现失败，都会使得整个流程中断，并将相应信息反馈至开发人员处。
4. 测试阶段: 这个阶段中代码被部署到测试环境并展开一系列的测试工作，包括手动的，自动的；功能的，性能的，安全的。
5. 版本准备阶段：测试阶段验证成功以后，可以认为代码已具备上生产的能力，测试通过的版本被标记为可以上生产，只需要手动或者自动操作(取决于项目规定)就可以将版本推送至生产线上。
6. 部署阶段: 将应用程序部署到生产线上。可以采用手动或者自动的方式来完成部署，同时可以采用蓝绿部署，金丝雀部署等方式来实现"零宕机"、安全部署。
7. 维护阶段: 应用程序上线后，运维团队需要确保应用程序运行环境的稳定，在访问量高的时刻能够快速扩容来应对峰值，访问量低的时候缩容以减少资源消耗。
8. 监控阶段: 监控应该包含两方面的：应用程序的监控和Pipeline的监控，借助于监控工具来获取一些有效数据，然后反馈给开发团队，或者运维团队，以此来进一步提高应用程序及Pipeline的稳定性，安全性。

三、持续交付演进

3.1 传统交付模型

在传统的分工模式下，各个阶段的职责分工明确，首先PD将需求提出来，开发者根据需求写代码，然后告诉SCM，SCM拿着代码去打包，打包后告诉QA，QA测试完成后通知运维OPS上线，OPS进行上线部署，最后整个需求得到release。

因此我们发现在此交付模型中各个阶段分工与责任清晰，质量有保障，层层制约，容易把控。但是劣势也比较明显：

1. 沟通成本与等待成本高，每一个环节都有成为瓶颈的风险;
2. 构建和维护成本高，在这个阶段中一般都是手动构建且手动部署的方式，构建和扩缩容成本高。

3.2 交付模型1.0

在传统的交付模型中，构建和部署成为了交付周期中的一大头，为了提高构建部署速度，市面上也涌现了许多工具，例如使用jenkins和git/svn作为持续构建工具，使用ansible或者saltstack作为持续部署工具, 以及一些列的主机(虚拟机)监控工具。

如上图所示，用户通过git工具上传代码，触发jenkins流水线，然后通过ansible下发到不同的虚拟机或者服务器上。因此通过自动化的方式使得整个应用流水线的交付周期被极大的缩减。但此时各团队协作程度还不够高, 虽然催生出了一系列自动化 / 半自动化工具(如 puppet、chef、ansible 等), 结合编写脚本的可扩展能力，将研发和运维的大量操作规范化，从而达到彼此协作的目标，但彼时各个团队还相对孤立。

3.3 云原生-CI/CD的加速剂

随着Docker和Kubernetes的开源，使得CI/CD得到了快速的发展。云原生提供的一系列能力如代码托管、持续集成、持续部署，到监控、报警、自动扩缩容等，使得越来越多的企业通过云原生进行流水线构建。

Docker提供的Build once, Run Everywhere的能力提供了一直的编译环境，解决了原本构建过程中的环境污染问题，同时由于docker提供了更为轻量的运行时环境，巨大的加快了持续构建的速度。随着docker天然支持微服务的特性，软件也被拆分了更小的微服务，因此整个软件交付周期变得更加频繁。
Kubernetes，Operator等云原生工具的快速发展为软件的快速持续部署提供了保证，kubernetes提供的快速扩缩容能力使得持续部署更加快速自动化。

3.4 GitOps-云原生下的持续交付模型

随着Docker和Kubernetes的流行, GitOps的交付模型也逐渐被大众熟知。
GitOps 起源于 Weaveworks 公司在 2017 年发表的一篇博客， GitOps - Operations by Pull Request，在文中，Alexis 介绍了一种以 Git 为唯一事实来源的部署方式。
GitOps的交付方式中，核心思想是将应用程序的声明性基础架构和应用程序存放在Git版本库中。将Git作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用Git来加速和简化Kubernetes的应用程序部署和运维任务。通过使用像Git这样的简单熟悉工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。因此GitOps主要由一下四个主要组件组成：

1. Git 仓库：用来存储我们的应用程序的声明式定义的 YAML 文件的源代码仓库。
2. Kubernetes 集群：用于部署我们应用程序的底层集群。
3. 同步代理：Kubernetes Operator 扩展，它的工作是将 Git 仓库和应用状态持续同步到集群中。
4. CD Pipeline：持续部署流水线，用来编排整个流程的持续部署流水线。

将GitOps应用在持续交付流水线上，具有诸多的优势和特点：

1. 提高生产力 - 采用集成了反馈控制循环的持续部署流水线可以大大提升新功能的发布速度。
2. 提升开发者体验 - 开发者可以使用熟悉的工具 Git 去发布新功能，而无需了解复杂的部署交付流程。新入职的员工可以在几天内快速上手，从而提高工作效率。
3. 行为可审计 - 使用 Git 工作流管理集群，天然能够获得所有变更的审计日志，满足合规性需求，提升系统的安全与稳定性。
4. 更高的可靠性 - 借助 Git 的还原（revert）、分叉（fork）功能，可以实现稳定且可重现的回滚。由于整个系统的描述都存放在 Git 中，我们有了唯一的真实来源，这能大大缩短集群完全崩溃后的恢复时间。
5. 一致性和标准化 - 由于 GitOps 为基础设置、应用程序、Kubernetes 插件的部署变更提供了统一的模型，因此我们可以在整个组织中实现一致的端到端工作流。不仅仅是 CI/CD 流水线由 pull request 驱动，运维任务也可以通过 Git 完全重现。
6. 更强的安全保证 - 得益于 Git 内置的安全特性，保障了存放在 Git 中的集群目标状态声明的安全性。

基于GitOps的交付模型，市面上也出现许多交付工具，如Argo CD, Jenkin X, Drone等。其中Argo CD是现有市面上最为流行的GitOps工具。

如上图所示，基于Argo CD的持续交付流程如下：

1. Argo CD 从 Git Repo 拉取应用的配置，部署在 Kubernetes 集群中。
2. 当有人新增功能时，提交一个 Pull Requests 到 Git Repo 修改应用的部署配置，等待合并。
3. 在 Pull Requests 合并之后，通过 Webhook 触发 Argo CD 执行更新操作。
4. 应用得到更新，发送通知

3.5 ChatOps-进一步压缩交付周期

随着DevOps的盛行，应用持续交付的周期被不断的缩短，以及人力的成本被迅速减低。但是彼时需要人为介入的工作还是略带繁琐, 例如我们要查阅某个应用的监控指标(如cpu指标)，需要登录到相关的后台去搜索查阅等一些列的操作。随着全行业的发展和人力成本的攀升，在团队所有角色间贯通的升级版DevOps逐渐登场，那就是ChatOps。

ChatOps这个词最早于2013年出现，最初由GitHub提出，他们发现在日常的工作中，需要不停的运行以下命令

git checkout -b feature/xxx 
# do sth. 
git commit -m "Bump version" 
git push origin feature/xxx 
# create pull request

每次需要进行代码提交，确认持续集成通过，代码部署，确认各项指标正常，代码合并等一系列的繁琐工作。于是他们开发了Hubot这个机器人，来帮助他们完成这一系列的工作。

ChatOps 以聊天室，即沟通平台为中心，通过一系列的机器人去对接后台的各种服务，工作人员只需要在聊天窗口中与机器人对话，即可与后台服务进行交互，整个工作的展开就像是使唤一个智能助手那样简单自然。ChatOps 以聊天室，即沟通平台为中心，通过一系列的机器人去对接后台的各种服务，工作人员只需要在聊天窗口中与机器人对话，即可与后台服务进行交互，整个工作的展开就像是使唤一个智能助手那样简单自然。

例如通过机器人获取监控指标：

通过引入ChatOps, 为持续交付带来了显而易见的好处:

1. 公开透明。所有的工作消息都在同一个聊天平台中沉淀并公开给所有相关成员，消除沟通壁垒，工作历史有迹可循，团队合作更加顺畅。
2. 上下文共享。减少因工作台切换等对消息的截断，保证消息的完整性，让工作承接有序，各角色，各工具都成为完成工作流中的一环，打造真正流畅的工作体验。
3. 移动友好。只需要在前台与预设好的机器人对话即可完成与后台工具、系统的交互，在移动环境下无需再与众多复杂的工具直接对接，大大提升移动办公的可行性(出门在外，如果紧急事项需要处理，可以通过手机迅速处理)。
4. DevOps 文化打造。用与机器人对话这种简单的方式降低 DevOps 的接受门槛，让这种自动化办公的理念更容易的扩展到团队的每一个角落。

3.6 AIOps-智能运维，发现交付过程中的问题

随着机器学习算法的成熟，通过运维算法来实现运维的自动化概念也被提出并实践。
AIOps是DevOps的进一步补充，AIOps就像是上帝视角，持续的观察诊断持续交付过程中可能出现的问题，进而进一步压缩交付周期。简单的理解就是: AIOps = AI + 运维数据 + 自动化处理 = AI + Devops。

AIOps，最初的定义是Algorithm IT Operations，是利用运维算法来实现运维的自动化，最终走向无人化运维。随着技术成熟，逐步确定为Artificial Intelligence for IT Operations——智能运维，将人工智能应用于运维领域，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维无法解决的问题。

AIOps平台主要通过整合分析IT基础设施、APM、NPM、日志、数字化体验监测数据，来提升IT运维流程的效率，而AIOps平台能力的ROI多是基于平均故障接手时间（MTTA）和平均故障修复（MTTR）时间这两个指标的降低进行评估的。目前 AIOps 的主要应用场景有异常告警、告警收敛、故障分析、趋势预测、异常检测、根因分析等
从Gartner发布的中国ICT技术成熟度曲线可以看出，AIOps正在从过高期望的峰值向下滑落，未来有望进入真正的应用实施阶段。这意味着经过几年的摸索与试错，AIOps有机会突破大规模实践的临界点，目前各大厂商都在进行AIOps的探索与实践

3.7 NoOps-持续交付的最终形态

Devops促进了各个团队的协作，已经通过持续集成，持续部署的过程加速的交付周期，但是，此时还是需要运营团队参与中，仍然依赖运营团队来处理细节问题，例如：基础设施配置管理、安全设置、备份、补丁管理等。
随着Serverless的盛行，原本的基础设施进一步下层，即用户无需关心程序运行环境、资源及数量，只要将精力集中到业务逻辑上即可，进而实现更快的应用交付

NoOps 是Forrester最初创造的一个术语，旨在提高生产力并比 DevOps 更快地交付结果。在理想情况下，开发人员永远不必与运营团队的成员协作。相反，他们可以使用一组工具和服务以安全的方式负责任地部署所需的云组件，包括代码和基础设施。托管云服务（如 PaaS 或无服务器）充当 NoOps 的支柱，并利用 CI/CD 作为其部署的核心引擎。

虽然现在Serverless还处于早期阶段，现阶段使用场景还比较低，但是Serverless为软件交付提供了另外一种方向。特别是中小团队，通过serverless不仅实现了软件交付周期更短，而且交付成本更低，因为不需要专门的团队维护基础设施。

四、总结

1. 持续交付是敏捷的逻辑演进:纵观工具链的演进，每一次改革均是为了更好的交付产品，它也将成为ALM（应用软件生命周期管理）的核心。
2. DevOps正在打破僵局:而驱动这个变革的背后力量就是DevOps，各个角色共同努力，以精益原则驱动应用软件的生命周期，实现高度自动化。
3. 持续交付将会改变需求管理的方式。要具备快速的交付能力，就需要从需求拆解入手，通过小单元来快速实现价值，提升交付量，避免需求膨胀。
4. 回归当下。随着CI/CD Pipeline 一直的发展演进，以云原生为基础的CI/CD Pipeline工具能够进一步提高CI/CD Pipeline的效率，加速云原生应用程序的构建。若引入机器人，可以使团队合作交流更加顺畅。