Devops在敏捷团队中的应用

什么是Devops

百度百科：旨在建立一种文化与环境，使构建、测试、软件发布得以快速、频繁以及更加稳定地进行。我的理解：研发团队在保证质量的前提下，提高交付效率的方法都属于 DevOps 的范畴。

Devops解决什么问题

整个版本周期较长，一般一个月才能发布一个大版本，线上常有问题投诉，需消耗较多精力排查和修复。无法满足客户对时间和质量的交付要求。

原因分析：

系统紧耦合，相互影响和阻塞

①多个子系统无法做到并行交付

②故障传播不可控，相互影响

③一端出问题，整个版本阻塞

mock测试不够，集成后问题爆发

①开发自测不足，缺陷蔓延到集成阶段

②自动化能力缺失，大量依赖人工处理

③团队间存在资源争抢，相互冲突严重

环境交付未归一化，发布效率低

①环境多依赖复杂，线下线上不一致

②环境准备时间长，维护成本高

③串行发布上线，发布时间长

发布周期长

部门墙

Devops所做的一切活动就是为了移除这道墙。

拆除墙

Devops如何落地

3个支柱：人、流程、平台

人+流程=文化，人+平台=技能，流程+平台=工具

Devops=文化+技能+工具

1.码农文化

以详细注释为荣，以注释残缺为耻。

以打印日志为荣，以出错不报为耻。

以代码重用为荣，以复制粘贴为耻。

以多态应用为荣，以分支判断为耻。

以持续重构为荣，以停滞不前为耻。

以单元测试为荣，以手工测试为耻。

以注重团队为荣，以孤傲自大为耻。

以总结分享为荣，以不求甚解为耻。

2.质量文化，可参考文章《我对研发质量的理解》

3.质量闭环

技术实践开展：

1.静态代码扫描，JAVA采用Sonar，集成阿里的JAVA开发手册，可参考文章《sonar集成ail-p3c插件》

2.CI/CD，制定CI原则

①小改动，逐步构建

②每人每天提交代码

③在主干上持续集成

④至少每天进行集成

⑤充分的自动化测试

⑥红灯需要立即修复

3.单元测试

从无到有构建，类覆盖率：0%→85.3% 方法覆盖率：0%→78.1% 行覆盖率：0%→58% 分支覆盖率：0%→ 43.9%

4.结对编程

•乒乓结对：甲进行代码编写，乙负责编写单元测试用例——适合两个水平相近的程序员组合

•驾驶员-领航员： 驾驶员编写实现当前任务的代码，而领航员需要引领代码的编写并负责审查代码。——以老带新的组合

优点：

•天然的备份

•天然的Code Review

•相互促进提高水平

•更容易找到更完善的解决方案

5.自动化测试

API自动化：Robot Framework是一款python编写的功能自动化测试框架。具备良好的可扩展性，支持关键字驱动，可以同时测试多种类型的客户端或者接口

UI自动化：Selenium也是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE、Mozilla、Firefox等

Devops平台

风火轮，一套集测试策略、研发技术实践的工具产品，为研发内部提供研发效能服务，满足持续交付需求，是一个Paas平台。

在LDS落地思考

物联网Devops的技术差异性：

①物联网平台复杂度更高。

②固件的技术实践如何开展，单元测试，CI/CD选型？

③固件和软件开发节奏有差异，版本发布火车如何制定？

④软件平台的技术实践如何开展?

⑤各端如何通过MOCK或第三方工具来保证各自开发质量？

⑥问题定位太复杂，涉及太多端数据通迅，如何快速排查和定位？

1.技术实践开展

2.各端的Mock测试

①沙箱测试

②引流测试

③第三方工具：dongle、上位机

④测试数据构造

3.问题定位平台

①Skywalking

②JS-SDK

③EFK

总结

一方面，随着业务复杂化和人员的增加，开发人员和运维人员逐渐演化成两个独立的部门，他们工具链不同，业务目标也有差异，这使得他们之间出现一条鸿沟。另一方面，行业竞争更加激烈，快速交付是企业核心竞争力的体现。 因此，devops提出了解决问题的办法：它提倡软件持续交付，频繁部署。它力图拆除开发和运维的部门墙。但只有观念和组织结构上的改变是不够的，一切必须建立在自动化的基础上。devops的本质是倡导开发团队拧成一股绳，紧密合作，频繁沟通，流程和工具只不过是大家合作得更充分，更广泛。将人的地位放在技术之前，将交流与沟通放在流程之上，才是devops提高生产力的根本。