最近在项目中实践DevOps，搭建了一套从需求到集成测试部署的流水线，流水线中包括了需求分析、开发、代码评审、静态检查、持续集成、版本存档、自动化测试、度量的闭环，通过快速反馈，打造高质量产品。用到的DevOps工具链包括tfs，jenkins，astyle，cppcheck，sourcemonitor，自研diff，制品库，robotframwork，度量系统，如下图所示。
用到的语言有jenkinsfile，yaml，groovy，py
一.流水线
我们的产品发货量较大，软件升级有时需要人工干预，犯错成本较高。使用DevOps一方面是大势所趋，另一方面也是希望快速反馈能应对快速变化的需求。
在搭建DevOps过程中遇到不少坑，下面就说说我遇到的坑。
1.需求分析环节
这里说的是开发测试团队的需求分析，tfs这个软件挺全，从版本到需求，再到测试，基本都涵盖到了。接到需求后，做版本规划，创建product Version，生成product backlog，features。features拆分到故事，关联测试用例，
2.开发环节
3.代码评审
静态检查
4.版本制做存档
5.自动化部署测试
下图是持续集成流程总览图(图1)
VerifyCI如图2
MergeCI如下图3
DailyCI如下图4
二.jenkins脚本编写
1.multibranch
三.有待优化点
这样的持续集成效率还有待提高。
1.去重
mergeci里的代码静态检查(风格、复杂度、cppcheck)，因为和verifyci重复了，可以省略。
2.更快
当软件架构优化后，模块之间解偶，各个模块独立编译、交付。此时verifyci和mergerci里的增量编译可以更快速，smoke测试可以准确选择相关用例，执行更精准的测试。
当全量编译速度更快后，可以将增量编译都改为全量编译。解决新代码做不进版本的问题。
我理想中更好的DevOps流程是这样。
虽然我们用了DevOps，用了这么多工具，但团队更重要的是人，是文化，和这些相比工具的作用是微小的，重要是我们怎么用它们，就好比一把宝剑，有的人用它练成绝世武功，有些人只能用来切菜。
