一万年太久,只争朝夕!

本系列博文已经介绍了单元测试,静态代码检查,UI自动化,Jenkins,等持续集成的关键元素,这些内容远不是全部,只是皮毛而已,但也足以让我们从零开始实践持续集成了 🙂

本文的着力点就在于结合我们的实际,简单论述如何开展持续集成,并大致分为:

  • 为什么
  • 是什么
  • 怎么办

三段论论述,那么

洪哥,我们动手吧!

为什么实施持续集成

先听听Martin Fowler是咋说的:

持续集成是一种软件开发实践。在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次,也可以多次。每次集成会经过自动构建(包括自动测试)的检验,以尽快发现集成错误。许多团队发现这种方法可以显著减少集成引起的问题,并可以加快团队合作软件开发的速度。

这段论述很简练,很靠谱,不愧是大湿!结合自己的经验,做一下本地化解释:

  • 团队成员既包括开发,也包括测试,DBA,SCM,等多种技术型角色,大家的工作成果也不仅仅是项目的产品代码,也包括测试代码,测试环境的配置,数据库的配置,外部依赖的配置,等
  • 产品(项目)的优质,按时交付,完成其商业价值,是以上工作集成在一起的共同结果,任何一个环节都不应该掉链子
  • 我们希望以上工作能够以持续集成的形式集成起来,运行起来,透明起来,发现问题,降低风险,持续改进

在另外一个层面,技术负责人(QA负责人,开发leader,等)须要一些静态的,量化的,宏观的指标帮助进行一些决策或者判断。这个项目的代码覆盖率如何?代码风格,编码质量如何?冒烟通过率如何?这些具有指导意义的指标可以很方便地从持续集成中产出

(我想象中的)持续集成是咋样的

是这样的,见下图:持续集成流水线(pipeline

Screenshot_2

 

 

 

 

 

 

 

 

 

 

 

 

  • 首先是编译打包(Build),之后是单元测试(UT)与静态代码检查(SA),之后是快速的接口测试(IT)及UI自动化(UI
  • 之后IT及UI的全回归,以及安全扫描(SS)与性能测试(PT),这个阶段耗时预计会长得多
  • 最后是归档(Archive):可以是给Git,Svn打Tag,也可以是把产出的Jar包,War包等,以一定的规则(例如:branch_revision_timestamp.war )命名后存档
  • 其中,Build环节,UT及SA环节,快速IT及UI环节,运行时间跨度不应该长于15分钟。人都是有惰性的,反馈越慢,越倾向于不运行==!这三个环节应该经常运行:每30分钟定时执行,或者轮询代码库(scm poll)执行,或者团队成员根据需求手动执行
  • 而截至Archive环节为止的整套pipeline,建议每天定时运行若干次(至少一次),产出一些经过全套测试的具有一定交付信心的构建物

更后面的,这个pipeline可以继续延伸至产品上线:将Archive环节产出的构建物直接分发至生产环境服务器,并无缝更新重启(印象中,豆瓣?七牛?已经有这方面的实践拿出来分享了?),上线后再执行一套针对线上环境的接口测试或者UI自动化,确保上线成功

这幅图中的一些环节,我们已经有了不少的实践和积累,比如:SA,UT,UI,以及它们的载体:Jenkins;更多的,相信也是可以搞定的 🙂

如何实施持续集成呢?

古人诚不欺我,一句话道破天机:

大事化小,小事化了

只要把实施持续集成的步骤,难点,风险点,一一分解,其可执行性就会大大增强,也有利于稳步推进,逐步收益

小二!show表格!

(由于排版原因,下表拉得很长,这里先给出概要:

1. 配置Jenkins平台

2. 在Jenkins上部署Build环节

3.1 在Jenkins上部署SA环节

3.2 使用Sonar对项目代码进行全面的静态代码检查

3.3 细化SA规则集合

3.4 制定跨项目的统一的SA规则集合

4.1 整理单元测试

4.2 将单元测试部署至Jenkins上面

4.3 孜孜不倦补充单元测试

5. 在Jenkins上部署测试环境的一键更新部署

6. 补充IT环节

7.1 编写UI自动化用例

7.2 在Jenkins上部署UI自动化

7.3 孜孜不倦补充UI自动化用例

8. 补充PT环节

9. 补充SS环节

10. 补充Archive环节

步骤 1
工作内容 配置Jenkins平台
风险 & 难点 将Linux服务器配置为Jenkins的node节点会涉及环境变量的配置,须要留意下
措施 & 建议 1. 请有经验的同事来协助下
2. 使用现成的Jenkins系统,例如:ci.hz.xxx.xxx.com
收益 Jenkins是持续集成的基石之一
步骤 2
工作内容 在Jenkins上部署Build环节
风险 & 难点 无任何风险,任何已在运作的项目,必须已经有了自己的一套打包机制(例如:一个shell脚本),只须要通过Jenkins去调用这个脚本即可
措施 & 建议 1. Build失败是绝对不能容忍的,建议使用极其醒目的标题(例如:你丫的,谁谁谁,你提交的代码导致Build失败了)发送邮件,popo,等
2. 有条件的项目组,可以采用Jenkins的XFP插件,使用一块专用的显示器,立在交通要道,动态显示当前的构建状态,Build失败就是一片红
收益 1. 大家熟悉下Jenkins的配置,练练手
2. 从最基本的Build开始,释放出“持续集成将要搞起,兄弟们注意了”的信号
步骤 3.1
工作内容 在Jenkins上部署SA环节
风险 & 难点 须要单独部署一个Sonar服务器
并使用Jenkins的sonar插件打通Jenkins与Sonar
措施 & 建议 1. 请有经验的同事来协助下
2. 使用现成的Sonar系统,例如:xxxtest10.xxx.xxx.org
收益
步骤 3.2
工作内容 使用Sonar对项目代码进行全面的静态代码检查
风险 & 难点
措施 & 建议 1. 开启所有的静态代码检查规则进行一次全面体检
2. 第一时间处理block及critical问题
收益 根据我们的经验,从未进行过扫描的项目,在第一次全面体检后,几乎必然会发现一些明显的Bug或者风险点。
对于项目而言,可以短平快地发现及处理一批潜在风险点,这也是为什么我建议把SA环节放在UT环节之前开展
步骤 3.3
工作内容 细化SA规则集合
风险 & 难点 全面体检后,几乎必然出现海量的报警,从海量的报警中,
抽取相对重要的,但也具备可执行性的规则集合,有点难
措施 & 建议 1. 恭请权威人士 or 经验丰富的老黄牛,辛苦下,整理规则集
2. 参见博文:http://chenkan.me/2013/11/08/ci_look_back_04_static_analysis/
收益 “路遥知马力,日久见质量”
产品的长远发展离不开优质的代码,优质的代码离不开严格的规范
步骤 3.4
工作内容 制定跨项目的统一的SA规则集合
风险 & 难点 跨项目,一堆人,你懂得
措施 & 建议 从上往下推行
收益 不怕不识货,就怕货比货,当一个新项目(产品)纳入持续集成后,
可以使用Sonar的横向对比功能与已有的产品进行对比,各项指标一清二楚,潜在问题一目了然
步骤 4.1
工作内容 整理单元测试
风险 & 难点 不得不承认,很多项目(产品)的单元测试是不完整的,甚至是不可运行的;
补单元测试是个很痛苦的过程
措施 & 建议 1. 如果是Java,推荐统一采用TestNG框架
2. 请有经验的同学进行短期培训 or 分享(我发现大部分开发同学对于写单元测试还是很积极的,只是缺乏合适的指引,不知道怎么写,何时写,如何运行,等)
3. 用例集合可以少一点,但必须保证可运行,有价值(必须有断言啊==!
4. 参见博文:http://chenkan.me/2013/11/03/ci_look_back_03_unit_test/
收益 单元测试是开发同学的基本功,基本责任;
良好的写单元测试的习惯对于个人和项目无疑都是很有价值的;单元测试是持续集成的基石之一
步骤 4.2
工作内容 将单元测试部署至Jenkins上面
风险 & 难点 单元测试并不一定都是全无外部依赖的,实践中,
单元测试或多或少都有些依赖(数据库,第三方服务等)
措施 & 建议 严肃处理好单元测试的各种环境依赖(使用:mock,stub,fake,等)
提高运行稳定性
收益 一旦单元测试可以在Jenkins上面跑了,我们就有了一个中立,
客观,稳定的地方可以随时查看,甚至追溯单元测试的执行通过率,代码覆盖率等关键信息了
步骤 4.3
工作内容 孜孜不倦补充单元测试
风险 & 难点 写单元测试是门技术活,得练
措施 & 建议 别偷懒,常写常新,越写越快
收益 技多不压身
步骤 5
工作内容 在Jenkins上部署测试环境的一键更新部署
风险 & 难点 无任何风险,任何已在运作的项目,必须已经有了自己的一套环境部署机制(例如:一个shell脚本),
只须要通过Jenkins去调用这个脚本即可
措施 & 建议 为持续集成申请单独的测试环境,多多益善
收益 为后续接口测试与UI自动化铺路
步骤 6
工作内容 补充IT环节
风险 & 难点 很遗憾,在这方面我涉及不多,没有总结提炼出经验 🙁
最近仍在探索。
比较可以出手的,也只有对于接口测试框架的一些设想:http://chenkan.github.io/blog/2013/02/24/http-test-framework/
措施 & 建议
收益 http接口测试一般由测试人员编写:
1. 可以在功能测试之余,写写代码,调节一下节奏
2. 接口测试与UI自动化具有很强的互补性
3. 对于移动端产品,接口测试具有更加重要的意义
步骤 7.1
工作内容 编写UI自动化用例
风险 & 难点 UI自动化,谨防:
1. 跑得慢
2. 不稳定
3. 维护累
措施 & 建议 1. 墙裂推荐使用Dagger作为UI自动化框架
2. 请有经验的同学进行指导 or 速成培训
3. 量力而行,不求高大全,与接口测试互补
4. 参考博文:http://chenkan.me/2013/10/26/ci_look_back_02_ui_automation/
收益 UI界面是用户与产品的直接交互面,也是测试人员的重要工作对象:
UI自动化不通过,用户不接受,测试人员的工作也会受影响
步骤 7.2
工作内容 在Jenkins上部署UI自动化
风险 & 难点 应该没啥风险吧
措施 & 建议 经过前面的磨练,部署UI自动化小菜一碟了吧
收益
步骤 7.3
工作内容 孜孜不倦补充UI自动化用例
风险 & 难点
措施 & 建议 及时维护,及时重构,用例分级
收益
步骤 8
工作内容 补充PT环节
风险 & 难点 没搞过性能测试,不敢瞎掰
措施 & 建议
收益
步骤 9
工作内容 补充SS环节
风险 & 难点 没搞过安全测试,不敢瞎掰
措施 & 建议
收益
步骤 10
工作内容 补充Archive环节
风险 & 难点 继续不敢瞎掰
措施 & 建议
收益

上述表格全景式地展示了持续集成的实施步骤,每一个分解步骤都有一定的可执行性,且尽量保证收益大于投入及风险:每前进一步,都有收益!

而且,很多环节可以是有现成的,比如:单元测试,接口测试,UI自动化,等,完全有可能一直都在使用着,只是没有集成起来而已

此外,在实践中,我墙裂建议:

  • “比所有事情都重要的是寻找帮助。找一个以前做过持续集成的人来帮你” – Martin
  • 在第一时间部署包括Build,UT(及SA),快速IT(及UI)这三个环节在内的猴版持续集成
  • 并使用Jenkins的Pipeline插件,展示这个持续集成(见下图,点击看大图
  • 用例可以少些,只覆盖核心功能,冒烟功能,静态代码检查规则集可以简略些
  • 猴版持续集成的部署意味着:打通了各个环节,配好了各个环境,一切都可以Run起来了,那么后面就是一心一意补充测试用例,补充更多环节了

j1

 

结束了

没啥可说的了,还是行动吧:

一万年太久,只争朝夕!

4 thoughts on “持续集成回顾暨点滴分享[7] – 实施篇,持续集成搞起来!”

发表评论

电子邮件地址不会被公开。 必填项已用*标注