DevOps实践

    最近在项目中实践DevOps，搭建了一套从需求到集成测试部署的流水线，流水线中包括了需求分析、开发、代码评审、静态检查、持续集成、版本存档、自动化测试、度量的闭环，通过快速反馈，打造高质量产品。用到的DevOps工具链包括tfs，jenkins，astyle，cppcheck，sourcemonitor，自研diff，制品库，robotframwork，度量系统，如下图所示。

用到的语言有jenkinsfile，yaml，groovy，py

一.流水线

图1Devops总览

    我们的产品发货量较大，软件升级有时需要人工干预，犯错成本较高。使用DevOps一方面是大势所趋，另一方面也是希望快速反馈能应对快速变化的需求。

    在搭建DevOps过程中遇到不少坑，下面就说说我遇到的坑。

  1.需求分析环节

  这里说的是开发测试团队的需求分析，tfs这个软件挺全，从版本到需求，再到测试，基本都涵盖到了。接到需求后，做版本规划，创建product Version，生成product backlog，features。features拆分到故事，关联测试用例，

  2.开发环节

3.代码评审

静态检查

4.版本制做存档

5.自动化部署测试

下图是持续集成流程总览图(图1)

图1 持续集成总览

---

    VerifyCI如图2

图2 VerifyCI

MergeCI如下图3

图3 MergeCI

DailyCI如下图4

图4 DailyCI

  二.jenkins脚本编写

1.multibranch

三.有待优化点

这样的持续集成效率还有待提高。

1.去重

mergeci里的代码静态检查(风格、复杂度、cppcheck)，因为和verifyci重复了，可以省略。

2.更快

  当软件架构优化后，模块之间解偶，各个模块独立编译、交付。此时verifyci和mergerci里的增量编译可以更快速，smoke测试可以准确选择相关用例，执行更精准的测试。

    当全量编译速度更快后，可以将增量编译都改为全量编译。解决新代码做不进版本的问题。

    我理想中更好的DevOps流程是这样。

图5 能自动推导需求的Devops

  虽然我们用了DevOps，用了这么多工具，但团队更重要的是人，是文化，和这些相比工具的作用是微小的，重要是我们怎么用它们，就好比一把宝剑，有的人用它练成绝世武功，有些人只能用来切菜。