CI/CD 理想模型

云原生下交付理念

随着k8s成为容器编排系统的事实标准，软件构建/交付发生了很大的变化。也许你还没有体验到历史车轮前进的痕迹，但它确悄无声息的一直前行。对于开发、运维人员 这也是一次小小的技术革命,既然是革命总有人(保守派)要为此丢掉原有的奶酪，另外一批人(激进的人士)或多或少出现一些弯道超车的机会，对于行业从业者来说既是机遇也是挑战。传统的运维、dba岗位需求将会越收越紧，开发不再只局限于产品逻辑开发，会不同程度的参与ci部分的建设。即ci会慢慢向研发端下沉，由运维提供构建规范。解放ci构建项目工程的自由度。
k8s以及(service mesh)服务网格的出现打破了互联网构建、交付技术循序渐进的脚步，从而实现不同以往的跨越(也可以称之为技术进步)
本文ci/cd理念便是在这种行业背景下产生的(个人感悟)。

• ci工具
  在当今以用户体验为主的互联网生存环境下，前后端服务频繁迭代将是常态，随之而来的代码频繁并发性的构建将是常态。随之而来的将是频繁性、瞬时大并发量的构建工程任务。
  常见的ci工具有jenkins、githubci、gitlabci、轻轻量级drone等。他们都是很好的开源工具，用各自的理念,高效处理以上状态下的构建任务，其中jenkins是出现时间最早，插件最多的ci工具。githubci是github最近发布 还处于beta状态。gitlabci是在gitlab在8.0版本开始加入的功能。

• jenkins2.0为适应云环境的持续构建
  1. 插件式构建过程：整个构建流程使用jenkins上各个插件，由jenkins提供参数选项，使用人员只需添加参数内容。这也是jenkins1.0时代的主要构建方式，2.0版本兼容了1.0的这种方式。
  2. pipeline：pipeline是2.0版本推出的，以适应现代化流水线、申明式的构建环境。其后续小版本逐渐增加了对云原生、k8s环境理念下的支持，其构建过程不再是插件界面拼凑而成。而是由Groovy脚本维护控制，文件内容一般放置在项目工程根目录下.jenkinsfile中
  3. Master/Agent架构方式，支持瞬时大量的构建任务
  4. 支持k8s，可以根据构建任务量级动态伸缩Agent构建节点。
  5. pipeline正在逐渐向声明式构建靠拢，以便其适应云原生环境的复杂构建过程，这也是今后的主流方式。
• Github ci
  1. 既然是github的产品，肯定是要依赖github，对于没有采用github的企业来说，无法直接使用，迁移到github代价也不小。
  2. 没有Master/Agent方式
• Gitlab ci
  1. 采用pipeline方式，其构建文件一般放在项目工程的根目录下.gitlab-ci.yml 版本控制跟随项目工程。
  2. 由Commit push操作触发构建操作
  3. 由于是gitlab内置功能所以比较耗费cpu、内存资源，大量任务时硬件资源是其瓶颈，毕竟gitlab原本就需要不少资源
  4. 无法动态伸缩节点，大量构建任务时会出现排队情况
  5. 没有Master/Agent方式
• Drone：drone是一种基于容器技术交付的持续构建、交付系统，采用声明式，其构建过程都可以是docker容器，采用yaml配置文件管理。
  1. 很新、很潮 基于容器实现，简洁、复杂度低
  2. 任务构建由git push触发操作，目前没有找到其它方式来进行构建操作
  3. 其配置完全由yaml文件控制
  4. 官方文档不完善、晦涩难懂
  5. 由于配置极简，功能不完善，不适合大量任务构建使用

• 对比发现 drone虽是云原生的，但是很多功能并不完善，大量任务构建时效率差，并且是以git push 来触发任务构建，这在大多数情况下是合适的，但是极端情况下，这种理念并不适合。需要有完善、规范的发布体系来支撑
  gitlab ci功能与gitlab深度耦合，并且不适合k8s环境下的构建交付

• jenkins现在只是跟上了云原生、k8s环境下构建、交付的脚步。并不是真正意义上的声明式构建工具
  但其高效的master/agent方式，完善的文档、pipeline的引入，让它还没有落后他人。在其它ci工具没有成熟、完善之前，jenkins还是比较稳健的ci构建工具。

• cd是什么

cd即持续交付，是在ci的生产物上进行的经过ci流程的一系列操作后产生了最终的交付物，但是我们怎么交付给最终用户使用呢，
交付过程中如何做到对用户无感知
交付过程如何做到发布失败对用户没有影响(或者说影响接近于0)
交付过程中如果新版本有错误如何做到安全的版本回滚呢
cd即是在这一复杂情况下诞生的。
在以用户体验为中心的互联网产品频繁迭代、开发、时期我们必须接受失败是一种常态、失败是安全的、低影响的。
在此理念下我们就知道了CD要做什么，而不是关注于cd工具本身。
业界关于cd(持续交付)有以下实践理念

• 自动化：这种理念下的交付对团队的技术能力要求很强，需要完善的制度来辅助处理自动化下各种复杂情况的出现。其流程上将ci部分的交付产物通过自动化测试用例检测通过后，发布到预发布环境，然后再次进行预发布环境的测试用例检测、通过后进行生产环境灰度发布、或者金丝雀发布，第三次调用测试用例进行检测。这3个环境的测试用例是否相同取决于项目工程的复杂性。如果生产环境的灰度发布检测通过，并且经受了小部分用户的使用检测没有异常，那么cd流程会继续向前推进、逐步加量直至全量发布完成新版本。在此期间各个环境如果测试失败应该由cd根据测试用例返回的结果来进行项目工程回滚，返回上一稳健版本。
  大中型公司、以及产品活跃用户少的初创公司采用此模式，初创公司并不是也具备完整的技术来支持，只是用户数量少，发布过程出现问题也不会对公司产品产生太大的影响。它们基本采用mini版本自动化发布流程。

• 半自动化：这是在自动化cd基础上为了更加稳固、安全的发布而做了一些妥协，放弃一定的敏捷性，提高发布质量。与自动化不同的地方在于每个环境的发布完成之后，再由研发人员、测试人员对功能再次验证后，再由发布人员进行下一环境的发布操作。以自动化测试为主，人工测试为辅。吸收了自动化的敏捷性、舍去人工重度参与的繁琐性。这里的发布人员有可能是开发，也可能是该项目的测试人员。运维人员在此环境下的参与度弱化，主要负责基础环境的优化、完善，敏捷性开发。

• 人工参与方式： 由开发人员或者运维人员同步发布平台进行各个环境发布操作，每个环境发布完成后由开发和测试进行功能验证测试，测试通过后通过IM或者口头通知方式告知发布人员进行下一环境的发布上线，然后再次进行验证测试，直至生产环境全量上线。可以看出各个环境的连接人为的进行了断点隔离，以便应对流程外的情况，而且也没有自动化测试用例、或者以人工测试为主自动化测试为辅，目前大多数创业公司员工数50-100人时采用此模式较多，这是因为这类公司一般产品活跃用户数量在50W-150W之间，对发布过程中的故障、问题容忍度低。对产品上线质量要求严格，但还没有比较完善的技术来支持自动化、半自动化方式。

• CD工具

理念总要有工具或者技术来实现支撑，cd的工具有商业、开源基本这两类，这里只探讨非商业项目
大多数ci工具都提供原生、或者以插件形式扩展集成了cd功能。jenkins、drone、gitlab
但是ci跟cd耦合在一起也会产生不便，如果某一版本发布一段时间后，产品或者测试发现了bug或者莫个功能的缺陷，此时有两种解决方案

1 研发修改代码上线新的版本解决
2 暂时将版本回滚上一稳健版本
当采用回滚方式时由于ci与cd高度耦合无法直接回滚，(除非手动登陆服务器操作)
其回滚会再次经历ci过程，即使跳过ci也会留下一个空的构建版本号。
大中企业一般是采用ci工具，然后使用自研的cd工具、或者平台；也有采用开源cd项目的。单纯使用ci工具处理cd流程功能稍显不足

k8s环境下的cd工具

• tekton

tekton 是一个强大而灵活的k8s原生开源框架，用来进行持续集成和交付系统，对底层细节实现进行抽象，可以实现跨多云平台、多集群系统交付。可以跟jenkins配合使用

• flux

CNCF维护项目，未毕业。 基于gitops理念。在git中声明性的描述系统的期望状态，使用YAML来进行强制一致性管理，所有更改都是通过git进行，使用差异化工具来检测状态跟期望状态的差异；提供原子性和事务性，操作要么全部成功，要么全部失败。

• drone

只支持容器环境，传统服务器软件交付不支持

• jenkins

利用k8s插件或者ansible进行cd操作，拓展性差。

• wayne

360公司开源产品，功能齐全，可视化好，不错的权限控制、审计功能。缺点是灵活性不够，配置项太多操作繁琐，没有提供pv文件的管理。所以操作都要通过前端web页面进行操作，不利于后期自动化处理。