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的本质是倡导开发团队拧成一股绳，紧密合作，频繁沟通，流程和工具只不过是大家合作得更充分，更广泛。将人的地位放在技术之前，将交流与沟通放在流程之上，才是devops提高生产力的根本。
