在企业推行DevOps，先规划好这几件事

1.先把代码质量做好

企业IT建设中想要推行DevOps，第一步先做好质量内建，质量内建的方式有哪些呢？首先我们通过自动化测试、重构、简单设计等手段，可以使在编码阶段引入的缺陷变少，因为我们代码写清楚了，bug就藏不住了。同时当我们做到自动化测试等工作时，在编码阶段发现的缺陷也变多了。那么通过质量内建，我们在编码阶段就把大部分的问题都捕获到，同时引入的缺陷更少，降低了软件的开发成本。

今年软件平台部的目标围绕着产出、质量、规范来推进工作，这半年来，缺陷数有明显的下降，产品的交付质量有较大的提升。在软件的过程质量管控取得了一些成效：

• 重视需求设计，在每个迭代开始的前半个月，PM内部就会组织需求内审，由PM老大整体把关，让团队内部聚焦于高价值的需求产出。内审完成后，组织研发Leader、架构师从技术上评估可行性，同时安排外部需求评审，并最终将需求文档落地到conflucence。PM、研发、QA的协作逐步变得有序和高效。
• 项目过程管控，去年PJM的项目管理主要还是依靠WBS，先由PJM将需求拆分成任务，再由技术Leader维护子任务，如果涉及到跨项目协同，整体WBS的维护工作量很大。项目开展过程中，如果有临时任务变更，调整WBS就更痛苦了。因此经常出现月初定的WBS计划，在实际落地的时候偏离较大，需求的交付不可控。今年项目过程管控最大的改变是回归平台(JIRA工具)，通过Scrum看板，维护需求/任务状态泳道，让状态流动起来，团队成员的协作可视，大幅减轻PJM的项目管理工作，同时也让成员更直观看出团队的产出和质量。
• 编码规范要求，静态代码扫描，sonar的质量门禁已经逐步建立起来，也把阿里的p3c编码规范集成进来，严重级别为Blocker、Critical的规则，研发开始重视并在迭代中任务进行修复。整理Restful的接口开发规范，新上的云端接口开发，基本都是按Restful规范来执行。
• 迭代评审验收，研发同学提测前需要进行迭代演示验收。由SQA同学提前准备演示剧本，研发要执行对应的业务场景测试用例，由PM和QA进行验收打分，通过3次迭代的试运行，效果还是显而易见的，缺陷数下降很明显。团队内部也逐步形成了这样的质量意识，对整体交付质量负责。Eat your own dog food，自己的狗食再难吃，也要含着泪吃完。O(∩_∩)O
• 聚焦全流程业务测试，之前Arnoo和workwith业务的测试是分离的，如产品创建流程、App打包流程。经常会出现两端测试没问题，但合起来业务流程走不通，有不少低级缺陷流出。重新梳理以业务场景重构设计测试用例，弱化Arnoo和workwith的系统边界。

2.快速搭建基础平台

1.CI平台

持续集成平台是整个DevOps的基础，当前是基于Jenkins来实现的，Jenkins社区很活跃，插件也很丰富。Pipeline是Jenkins2.X的最核心的特性，帮助Jenkins实现从CI到CD与DevOps的转变。Pipeline将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排与可视化。Pipeline是一组插件，让Jenkins可以实现持续交付管道的落地和实施。初步先定义以下3条Pipeline：

• 提交阶段的Pipeline，代码提交后，自动触发静态代码扫描，严重级别为Blocker、Critical的规则需要修复完成方可提交。
• 验收阶段的Pipeline，Feature分支合并到Dev分支后，自动触发自动化测试、性能测试、安全扫描，这些测试用例执行异常需要马上修复，通过且研发自测OK，方可发起Merge Request。
• 线上部署的Pipeline，选择发布策略(灰度、蓝绿、滚动)，通过Ansible部署到公有环境，并通过监控公有云主机、组件服务状态来发现发布后是否存在异常。

2.ATP平台

ATP平台是自主研发的，一个集自动化用例管理、多终端UI、固件自动化、安全、性能测试等多功能一体的自动化测试管理平台。

• 缩短软件端测试时间，测试分层，将一些功能测试用例通过API、APP自动化测试覆盖；pre回归测试，自动化测试用例先行，手工测试为辅，缩短测试周期；减少繁锁的重复性测试，如多语言文案，手机兼容性测试。
• 提升固件测试效率，开发各种不同协议的客户端，ZB/WIFI/zwave/BLE，将一些功能测试用例通过脚本实现自动化；发现一些低概率事件问题，如配网成功率、设备控制等。
• 提前发现系统性能问题，web后端、api、MQ集群的性能压测，提供性能分析报告：响应时长、吞吐量、CPU/内存/IO等；每个大版本发布之前都会触发性能检测，通过高并发模拟用户请求发现系统的性能瓶颈，提前规划资源。

3.发布平台

上半年运维基于K8S容器化的升级改造已全部完成，目前的发布基本还是半自动化，人为工作量不少且容易出错。K8S基于容器化编排，通过定义Deployment，就可以快速实现灰度、蓝绿和滚动发布，这个发布平台需要满足以下几点：

• 对已部署的组件版本追踪
• 全球多数据中心：统一部署管理
• 多种应用的部署方式：传统java、镜像
• 多种部署方案：部署顺序（多服务依赖串行、并行），部署上下线方式（更新实例步长、更新下线方式）
• 部署系统全部平台化操作，无需登录服务器进行人为操作
• 完全自动化，满足CD交付要求

3.如何来度量

DevOps落地是否带来了交付效率和质量的提升，如何度量就显得尤为重要，度量指标前期可以先考虑以下几个：

• 平均需求交付周期，从需求提出，到需求可正常交付使用的时间，衡量研发的产出效率；
• 单测覆盖率，重点关注行覆盖率和分支覆盖率；
• 自动化测试覆盖率，主要是API的覆盖度；
• 测试金字塔比例，手工测试占总测试任务的比例；
• CI构建成功率，持续集成的稳定性和性能；
• 自动化部署成功率，部署时长，衡量发布平台的性能和稳定性。

1.数据采集

从当前的各种平台(JIRA、jenkins、sonar)提取有用的数据，可以考虑流水线设计的思路，通过插件来实现数据采集，架构示意图如下：采集器是针对每一个对接的数据源平台实现的，它的作用就是对每个数据源进行数据建模，从而对平台屏蔽各种数据获取方式，将采集到的数据进行统一格式化上报和存储。在采集器上面可以设计一个 Operation 层，用来调整采集器的执行频率，控制采集数据的范围。如果数据量比较大，你也可以让采集器对接类似 Kafka 这样的消息队列，这些都可以按需实现。这样一来，新平台如果想要接入，只需要针对这个平台的数据特性实现一个采集器即可，平台的整体架构并不需要变化。

2.看板度量，通过看板可直观的了解这些关键指标的度量数据，很清楚地看到在DevOps推行后，研发效能是否有效提升，对度量较差的数据持续改进优化。