CI&CD落地实践-目标规划&工具、技术选型

5,418 阅读10分钟

我正在参加「掘金·启航计划」

背景

最近公司越来越重视代码管控和发版质量,目前采取的策略是:

  1. 研发人员每天提交一次代码,每周五进行一次集中式编译、打包、发版等一系列活动;
  2. 代码需要研发人员先在本地编译通过后再提交代码仓库,在指定的执行机上由测试人员进行拉取代码、编译打包,然后测试手动上传到开发、测试、预发布等各个环境进行替换发版,最后再登录各个系统查看有无最基本的问题;
  3. 每次构建,要确保能够顺利通过,发版后不能影响到旧功能,新功能不能出现影响业务流程的报错,最终提交的代码才能视为合格有效;

这么做的好处是:

  • 明确了研发与测试人员的职责边界:研发就是写代码、上传代码,不负责编译、打包,测试人员负责编译、打包、发版等活动,避免研发人员私下修改代码;
  • 隔离开发人员本地环境与编译环境:研发人员本地编译通过,再提交代码至代码仓库,由测试在第三方机器上进行拉取代码,执行编译,二者环境相互隔离、互不干扰;
  • 确保了每次提交的都是有效代码:提交的代码不能影响到旧功能,也不能出现明显错误;

但带来的弊端也显而易见:

  • 流程长:研发提交代码->测试拉取代码->测试执行编译、打包->测试将打好的包替换到指定服务器->重启服务、完成发布,手工测试验证基本功能;
  • 成本高:流程长同样也带来了高成本,众多项目叠加在一起,测试每个项目都要验证,平均每周五需要花费至少1-3h的时间成本;
  • 效率低:沟通都是通过口头或微信消息传达,研发人员完成代码上传后口头告知测试人员可以进行编译了,测试人员再走到指定机器的工位上执行一系列动作,成功后再口头或聊天消息告知相关研发和领导验证通过,整个过程下来,效率比较低下;
  • 过程不可控:每天仅仅是上传代码,不在第三方机器执行编译,每周五才集中式编译一次,无法有效感知研发每一次提交的代码是否有效,与敏捷模式下“快速反馈”的思想相背离;

为了解决以上问题,我们测试提出采用CI&CD(持续集成&持续交付)的形式来分阶段替代上述所有流程。但其中涉及的环节比较多,在此之前我们也没有相关经验,所以我们决定边学习边摸索,采用机器+人工两条线并行的方式,即:

  1. 原来人工操作的机制还是先由人工完成;
  2. 与此同时,搭建CI环境,配置好各个项目,再由CI慢慢替换掉原有的手工流程;
  3. 眼前的首要目标是先实现项目的快速构建、快速反馈,待后期CI&CD流程建设到一定程度,团队内部也养成了这种文化氛围,再由CI&CD完全取代人工,实现最终的持续集成-持续交付!本系列文章主要记述CI&CD的学习及落地实践过程。

一、什么是CI&CD?

按照惯例,还是要介绍一下相关概念:

1.持续集成(Continuous Integration)

持续集成(Continuous Integration)简称CI,持续集成强调开发人员提交了新代码之后,立刻自动的进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起;

2.持续交付(Continuous Delivery)

持续交付(Continuous Delivery)简称CD,指的是一种能够使得软件在较短的循环中可靠的发布的软件工程方法。它是在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」( production-like environments)中,如果代码没有问题,可以继续手动部署到生产环境中。

持续交付的作用:

  • 对于要交付到功能,提供更快的交付方式,可以将改动的代码快速交付到生产环境;
  • 有能力进行交付,但并不一定是任何改动都要立马交付,更多强调的是快速交付的能力;

3.持续集成 VS 持续交付

交付产物不同,产生交付物之前的流程为CI-持续集成,产生交付产物后、将交付物发布到各个环境的流程成为CD-持续交付。所以CI和CD的最大区别就是交付物的不同。

4.持续部署(Continuous Deployment)

持续部署是持续交付的下一步,是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。

5.持续交付 vs 持续部署

持续交付和持续部署都叫CD,但持续交付强调的是代码集成后能够实现自动化测试的能力、快速交付、自动发布的能力(具备这种能力,但并不一定马上要用到),通常还是采用手工发布到线上的方式;而持续部署更多强调的是一种方式,全流程、自动化发布到线上的方式。

二、工具&技术选型与目标规划

1.工具选型

目前支持CI&CD的平台有:

  • gitlab-ci:git官方的持续集成工具,在Git工程管理页面上,也有专门的CI配置和展示页;
  • Travis CI:只支持 Github,并且绑定了Github上的项目,不支持其他代码托管服务;
  • TeamCity:由JetBrains创建的基于Java的CI / CD工具;
  • Jenkins:开源的、提供友好操作界面的持续集成(CI)工具,主要用于持续、自动的构建/测试软件项目、监控外部任务的运行。可在Tomcat等流行的servlet容器 中运行,也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT,构建 工具有Maven、Ant、Gradle。

虽然Jenkins只是支持持续集成的众多工具之一,Jenkins ≠ 持续集成,但目前只要一提到Jenkins,人们就会联想到持续集成、CI&CD,可见其使用范围之广,用户之多。同时资料也最为丰富、社区最活跃,所以选择Jenkins也没有什么好犹豫的。

2.技术选型

  • 平台基础:Jenkins
  • 静态代码扫描:Sonar&Sonarqube
  • 前端构建环境:NodeJS
  • 后端构建环境:Java+Maven
  • 自动化测试环境:Python3+Allure+Pytest+Requests(接口)+Selenium(web)+UiAutomator2(APP)

3.CI 阶段目标

阶段目标一:自动化构建

先解决“人工拉取代码-执行编译-通知团队”这个原本手动执行效率低下的问题,最终效果:研发提交代码-->触发webhook-->Jenkins自动拉取代码-->编译打包-->通过插件实时企微群通知,后续的发布替换还是由手动完成,一定程度上达到了节约时间,降本增效的目的。

阶段目标二:静态代码扫描

在CI阶段,自动化拉取代码、自动编译只是过程,不是目的,重要的是要能够实现快速检验、快速反馈。这其中很重要的一个手段就是单元测试。但就目前团队现状而言,单元测试不现实。

我们采取的是接入自动化静态代码扫描来替代单元测试,最终效果:研发提交代码-->触发webhook-->Jenkins自动拉取代码-->静态代码扫描-->编译打包,实现最基本的静态代码扫描,代码覆盖率检测,避免出现低级语法规范和一些安全隐患。

阶段目标三:自动发布

解决手动替换发包的问题:自动编译打包后,通过shell脚本自动将发布包发布到开发、测试等各个环境。

3.CD 阶段目标

阶段目标四:自动化冒烟测试

应当说持续交付这个阶段最考验的就是交付产物交付到各个环境以后的自动化测试能力,需要具备完善的自动化测试手段,以此来保障快速反馈,否则很难体现CD的效果。除了前面提到的单元测试、静态代码扫描,还包括如:组件集成测试、接口测试、UI测试、性能测试、安全测试等等。

在阶段目标四中,我们主要实现两个类型的自动化测试:

  • 接口测试:校验各个接口是否连通,接口业务场景是否能够正常串联执行;
  • UI测试:校验系统是否能够正常登录,一些基本的冒烟测试用例是否正常执行;

阶段目标五:Pipeline流水线改造

将以上流程全部通过自动化手段实现以后,再利用Pipeline流水线语法进行改造,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂发布流程。

三、更文计划-夺命十三剑⚔

看过三少爷的剑的都应该知道燕十三的“夺命十三剑”,我姑且给本系列取个名《CI&CD夺命十三剑》。计划写十三篇,后期如有意外或偏差,再适时调整:

  1. 第一剑《工具&技术选型与目标规划》
  2. 第二剑《Jenkins环境搭建&解决无法安装插件问题》
  3. 第三剑《Jenkins版本升级与踩坑实践》
  4. 第四剑《Jenkins实现前端项目自动化构建》
  5. 第五剑《Jenkins分布式环境搭建及多节点运行》
  6. 第六剑《Jenkins接入maven自动化构建后端项目》
  7. 第七剑《Jenkins接入pytest+allure自动化测试项目》
  8. 第八剑《SonarQube环境搭建》
  9. 第九剑《Sonar Scanner使用配置&SonarQube项目命令行接入实践》
  10. 第十剑《Jenkins集成Sonar&分析前后端项目》
  11. 第十一剑《Pipeline流水线基本语法学习》
  12. 第十二剑《使用Pipeline流水线改造Jenkins Job》
  13. 第十三剑《Pipeline流水线接入质量门禁》

四、X因素

CI&CD,除了最关键的流程+工具,我认为还有勇气、技术、耐心:

  • 勇气:并不是每个公司或团队都有勇气,愿意从上至下、花费大量的时间和成本来推动开展CI&CD;
  • 技术:如果要完善整个链路,中间涉及到的技术栈非常广泛,自动化测试能力、运维能力等,对技术也是一种考验;
  • 耐心:最不可或缺的我认为是耐心,因为CI&CD在实施过程中,并不是简简单单配置几个Job就算落地完成,效果也并非立竿见影,可能需要很长时间的打磨、不断调整,同时也需要团队各成员的紧密配合等,非常考验团队领导以及成员的耐心。

作为测试人员,如果能推动并落地CI&CD,不仅能够为公司、为团队带来价值,同时个人能力也可以得到全面提升。