基于Devops的厘米秀项目实践经验分享
基于Devops的厘米秀项目实践经验分享
基于现在研发变革的大背景，可能需要每个技术同学有更多的新思路特别是在测试方面会接受比较大的挑战，上半年在思考如何能更好让手头上的工作跟公司的整体相契合，一直没有很好的思路或者方向。在前辈的相关引领和沟通下，参加了一些介绍课程和评委工作对devops有了初步了解，也强迫自己学习一些理论并开始一步一步的展开实践。此文章主要是跟大家介绍下devops的理论和具体项目的实践开展过程，希望给其他同学有一些帮助和引导。
01
devops基础理论学习
首先好的实践应该是在有充分知识储备开始，理论学习主要是通过DevOps实践指南这本书，这本书通过很多举例及实践三步法的步骤开展讲解，思路还是比较易懂，所以推荐读一读。
根据书的内容大致作了读书笔记和自己的理解，想快速浏览的可以参考下面的内容，这里主要把跟测试相关比较紧密的进行了梳理，当然一些内容可能是比较不适合每种技术架构（例如分钟级的部署等），需要结合书本里的例子来看会理解更加深刻些。
DevOps实践指南读书笔记：
第一部分 DevOps介绍
1）敏捷、持续交付和三步法
第一步：流动原则
a.工作可见（工作可视化）
b.单件流（限制在制品数、减小批量大小）
c.减少交接次数（审批、沟通等）
d.持续识别和改善约束点（环境搭建、代码部署、测试的准备和执行、解决紧密的耦合架构）
e.消除价值流中的困境和浪费（半成品、额外工序、额外功能、任务切换、等待、移动、缺陷、非标准或手动操作、填坑侠）
第二步：反馈原则
a.及时发现问题
b.群策群力，战胜问题获取新知
c.在源头保障质量
d.为下游工作中心而优化
第三步：持续学习和实验原则
a.建立学习新组织和安全文化
b.将日常工作的改进制度化
c.把局部发现转化为全局优化（经验分享）
第二部分 从何处开始
1）选择合适的价值流切入
a.绿地项目和棕地项目
2) 理解、可视化和运用价值流
a.确定创造价值的团队（涉及角色范围）
b.针对团队工作绘制价值流图（需要等待的工作、引发和处理返工的工作）
c.为非功能性的需求预留20%的开发时间，减少技术债务
d.运用康威定律
e.将运维融入日常开发工作
第三部分 第一步：流动的技术实践
1）为部署流水线奠定基础
a.新增集成团队：在过程中保证质量，而不是事后检查质量
b.按需搭建开发环境、测试环境和生产环境
c.应用统一的代码仓库
d.运行在类生产环境（开发过程中多次在生产环境运行代码）
2）实现快速可靠的自动化测试
a.如果问题发现太晚，会消弱从错误学习的能力
b.制定规则：只接受通过自动化测试的变更；持续集成流水线；测试覆盖率指标；
c.代码变更后触发单元、集成、在生产环境的验收测试
d.持续集成部署
e.构建快速可靠的自动化测试套件（变更发生时快速反馈）
f.自动化由快到慢的分类：单元测试、验收测试、集成测试
g.理想的测试金字塔：单元测试捕获大部分错误
h.先编写自动化测试（测试驱动开发和验收驱动开发）
3)应用和实践持续集成
a.应用基于主干的开发实践
4)自动化和低风险发布
a.发布日常化
5)降低发布风险的架构
第四部分 第二步：反馈的技术实践
1) 建立能发现并解决问题的遥测系统（遥测：远程测量。采集并传送运行参数）
a.需要解决的：需要问题出现时，没法定位原因
b.生产环境的事件、指标、日志
读书感悟
整体读下来，这本书更注重的是实践，所以在devops上好处并没有太多的内容，而是通过devops实践前后的公司的数据对比进行间接的证明。总体思路是实践三个步骤出发：
1
流动原则：怎么让技术价值更快的流动
这里去年腾讯zengyu老大也发过一篇内容，可以说思路是匹配的，下图是文章内摘要：
简单来说，让本该失败的创意快速失败，而让本该成功的创意快速成长，也许才是一个团队寻找正确答案的正道。所以从这个角度来看，效率即等价于创新的机会成本，其实具备战略上的重要意义。
兵法有云：“凡战，以正合，以奇胜。”如果说“以奇胜”是在各种层出不穷的创新点上寻找机会，那么我认为“以正合”是让创新效率变得更高，就是我们经常说的“敏捷”。所谓敏捷，就是极致地缩短每一次尝试和、反馈和决策的时间。
从我的理解来说，其实我们首先第一步是找到技术价值流过程中，哪些是流速特别慢，或者说有瓶颈或者甚至停留倒退的地方。单件流、小批量发布等策略的制定也是根据这种思路下的产物。在这种前提下，对自动化测试的依赖特别大，所以书在具体的实践开展时花了很多篇幅讲解了要实现快速可靠的自动化测试，这也是目标，但实际的国内技术大背景下，确实不能把国外的方法完全搬过来使用（开发自主进行的大量单元测试等），所以如何找到更适合手Q、腾讯或者国内的自动化测试策略和架构是首先就要思考的问题。
2
反馈原则：让问题更快的反馈到上游题
现在的反馈其实相对来说还不够快，如用户反馈问题后可能需要很多流程（如运营、测试）及筛选才能达到开发，产品需求也需要经过一些时间才能看到真实的用户数据。
3
持续学习和实验原则
总体来说就是建立比较好的技术文化氛围。出现问题后，每个相关角色主动来一起去解决和规避，而不是出了问题去指责或者惩罚。实验原则即是在这种文化前提下，大家能有更多的试错机会，对技术创新有比较多的帮助。
02
Devops在厘米秀项目上的实践
基于实践三步法，前两步是可以直接开展的。
所以基于流动原则上来看，我们首先要分析业务的技术流瓶颈，推荐使用一种价值流图来说明，下图是4月份，厘米秀2.0项目（3D项目）v1版本的价值流图：
可以通过这样的图，清晰的看到绿色部分其实是有价值的（有效开发、有效测试等），但可以从图中看到几个比较关键的问题：
1、素材问题较多，增加等待时间。并且在这个期间bug修复与的回归的工作效率很低。
2、手Q系统测试发现问题后需要不断的发布脚本或so修复，流程和沟通占用时间很多，并且之前的模式是人工在群里丢包提测，回滚的时候还找不到之前发布的包。由于引擎技术的原因，修改影响功能范围大。在除了修改验证外，每次发布都需要进行全量的厘米秀核心功能测试。
3、因为渲染引擎的项目对性能测试及监控需求较高，手工测试性能数据的效率比较低，并且也比较滞后。
找到瓶颈问题后，其实解决方案会更加明朗些。
1、首先我们在素材监控上做了对应的静态检查和渲染测试的监控手段，并且在流程上项目组推动了素材上架的流程规范。可能在具体的方案不是最好的，但初步解决了问题。
2、在解决厘米秀脚本和so的问题上，引入了腾讯自研的蓝鲸平台，具体的接入方式可以参考蓝鲸的相关文章，主要是从提交触发开始，整个技术价值流水线开始滚动，可以参考下面的流水线图：
（小tips：蓝鲸支持bash命令的插件解决了很多我们的问题，例如我们会把git的提交信息通过bash命令进行逻辑化处理，从而区分每次构建的包的内容。通过bash命令和流水线的自定义全局变量可以进行通信的作用。）
通过强大的通知自定义功能，我们对消息通知进行改造，在插件中增加了CodeCC静态扫描、开发leader确认，自动化测试、和人工测试，并且串联起来，如果任意步骤有问题会认为这是失败的也不会发布或者合入代码到master上。
对于自动化测试的挑战：通过这样的流水线后，我们发现如果要应对比较频繁的提交测试时，自动化测试稳定性和是否快速是第一个解决的问题，现在我们是通过测试包跑核心的UI自动化测试，这种方案不稳定而且效率也比较低，违背了devops的快速反馈原则（见下图），是否有更好的技术方案这也是面临的需要解决的问题。
3、在性能测试效率上面，在自动化平台上做了性能自动化的测试（cpu、耗时、内存）释放了重复手工测试的工作，但同样也是有上面这个问题：是否稳定可靠和快速。应该也需要有更好的方案
完成了上面的优化工作后，我们再回头看下厘米秀2.0的v3版本的价值流图，这里可能更加贴合devops的思想
上图主要是说明在APP部分增加了素材监控；在手Q部分，去掉了专项的系统测试，再提交合入前就开始进行，并且提交触发流水线。针对每次代码提交的合入，我们都认为是不能带有问题的合入。这里也有了另外的挑战，如何在提交阶段进行充分的集成测试？
当然从这个价值流图这里还是有一些问题需要持续优化，例如分层测试没有阻断代码提交等。
03
经验总结
devops是一种思想，可能这里业务实践并不适合其他技术形态的产品，但方向上是行的通。在厘米秀上devops只是做了最先的第一步流动分析，通过分析找到一些瓶颈问题的解决方式，从而也发现对测试技术的挑战。并且这种分析是可以持续进行的，不光是研发相关的工作，整体的相关角色也可以适用（例如厘米秀现在内容设计有很多流程效率问题，是否也可以接入蓝盾流水线？）后续在厘米秀这里还要进行快速反馈的实践，这里还没有找到比较好的思路，期待有更多的同学能给予建议或者说已经实践的应用。
END
图片均源自网络，如有侵权请联系后台删除。