ci/cd

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-200W之间，对发布过程当中的故障、问题容忍度低。对产品上线质量要求严格，但尚未比较完善的技术来支持自动化、半自动化方式。