做CI的这一年

CI是什么

CI（续集成Continuous Integration)，我的工作内容：当开发将代码上到gitlab或者其他代码仓库后，到推送测试需要用到的测试包之间的所有工作。

具体工作内容

版本构建

• 通过jenkins/icpci等平台将代码下载到编译执行机（公司提供的大网IP虚拟机）进行编译、打包，并且推送到冒烟共享区，这个过程包括了编译，打包，推包脚步编写。
• 编译脚本：需要开发提供编译方式，比如，cd到对应代码目录，执行那些命令（我们项目用的C，所以入口是Makefile，cmake），我们将对应整个项目的编译逻辑（顺序）进行整理后编写为shell脚本（因为模块间可能存在构建依赖）
• 打包脚本： 需要开发或测试提供他们需要的包里面包含那些文件，并且告知文件来源与在包里的对应存放位置（有些为系统文件，有些是之前编译的结果文件）。
• 推包脚本：也就是打包完成后，需要将包存放的地址，一般和测试经理对齐后，固定一个地址，每日构建都存放于此，在jenkins中一般通过ssh插件存放到自己特定的某台服务器并做备份（最近30天）

个人构建

• 通过vscode或者其他平台链接jenkins搭建，具体不细说，结果包一般放在制品，方便取

静态检查

• 对代码质量进行检查：规则比较多，比如安全性，结构完整性，代码重复率等等，一般不需要编译，但有些也是需要编译的

环境维护

• 这一点是最重要的，因为上面的事情大多有人指导或者有文档，在或者有相应工具支撑人，但是这个主要看自己对问题的解决能力
• 比如我遇到的问题：
  1. 某一次，开发用到了cmake3的语法，而当时版本构建用到的环境是cmake2，开发在没有个人构建（自己编译一下代码）的情况下上库，从而导致版本构建失败。由于是新手，什么都不太了解，比较急，但是又没人可以请教，因此只能自己搜索。根据报错内容，在stackoverflow后发现是cmake版本造成语法不兼容问题，因此在直接通知版本经理和对应开发后，及时安装新工具解决，但是由于错过冒烟时间，从而导致测试经理不开心了（无奈）。
  2. 对构建环境进行升级替换，当时用的suse11，后面告知不能用，需要升级到centos7.5，因为当时不熟悉docker技术，被迫只能根据计算云一步步操作重装系统，然后重装构建工具等，由于环境多，因此重装2台后自动化脚本就出来了，不久后又因为产品用的是centos7.6，又要升级一次，（此时很庆幸自己已经搞出来自动脚本）。在后来才接触到ansible，感觉发现了新大陆。
  3. 下载代码失败，是因为空间不足造成，或者内存不足。出现这种情况后，马上搞了一个cron（定时执行计划），并且编写了对应脚本，进行定时检查。因为出现这个事故是版本构建，影响成功率，从而导致不好的影响。之后了解的另一个神器zabbix（实时监控环境状态，并可以自己编写处理脚本）

感受

• 感觉事情比较单调，特别是在环境维护做的比较好后，感觉基本无所事事

发展

因为CI属于DEVOPS中的一环，因此可以尝试走运维开发这条路，由于我之前python还是比较流畅，因此组内有相关事物比如爬取静态检查结果，并以email发送到相关开发会让我来处理。