大多数IT从业人员都会在30岁左右突然陷入绝望谷底，发现和年轻人比技术毫无优势自己吃了几年老本闲下来一想毫无核心竞争力。
那么随着第一曲线的功能（业务）测试到进阶的基于技术（开发）测试的深入后，应该如何继续保持自己的上升通道呢？TestOps架构师课程就是为了解决这个问题产生的，构建理念 技术/深度 广度的质量效能体系。
从2019年开始讲Spring的测开架构到2020年讲Go微服务开发，再到2021年中引入了DevOps平台开发的内容，一直保持着讲一门“走在行业前端”的课程，也对于讲师提出了较高的要求，讲有用的东西而不是迎合听众的东西。
而本次交付后讲师也做出了自己的总结：
背景
首先先简单介绍一下背景。“故事”起源于一次我与云大的学习交流，因为也是今年才开始慢慢接触敏捷和DevOps相关的东西，碰巧公司组织架构变化，所以从测试开发的角色转向为产品设计的角色。有一次我将目前在公司做的DevOps平台的一些特性与云大交流了一些想法之后。云大说让我去做一次课程的分享，本来是不太想讲的，因为感觉当时自己做的东西还不足以给VIP的同学们去交流，总有点班门弄斧的感觉，也是对于自己没啥信心吧。后来意识到关于DevOps平台从0到1的建设经验，网上也还真的找不到一个相对比较完善的实践分享，这几年感觉自己在这块应该也还踩了不少坑，可以和大家谈谈，于是便开始了我的下一阶段“备课”。
备课
前期其实主要还是讨论要讲的内容的侧重点，因为关于DevOps平台从理念、设计、开发、推广等，有蛮多东西的。但是也不是都适合拿出来讲，于是根据目前学员的一个综合情况我和云大沟通下来打算重点讲一下平台建设、自动化测试、第三方平台的整合、主代码实现。其实也希望学员在听完之后自己能对于DevOps平台的整体设计理念及相关开发知识有个了解，还有就是帮助大家去避免掉一些坑（有些东西我讲一下可能就1个小时就讲完了，但是真的自己去弄的可能要折腾一两个星期，因为我也是这样过来的）。
在有前几期整个微服务架构开发、自动化框架设计思想等课程的基础铺垫，所以这次课程也就可以围绕着一些框架的整合，常见的优秀框架二次开进行。
课程大纲
课程大纲如下：
简单介绍一下大纲内容，主要是结合自身的理论以及目前开发DevOps平台的一些经验，如果需要开发一款DevOps平台目前需要的最少MVP。还有一个方面的考虑是希望VIP的学员对于整体DevOps平台能有一个相对全面的了解，即使是自己目前并不开发这样一个平台，在使用其他类似DevOps平台时也能清楚的知道为什么这里需要“这样一个功能”，这个功能放在这里设计的意义是什么；第二个目的是如果有一天公司想要做这样一个DevOps平台，自己能够提出自己的建议或者能作为平台的设计者参与到devops平台的设计，这样对于一个测试人员来说也是有蛮大的帮助的-,-。
接下来根据上面的思维导图按照每个阶段内容进行一个简单的回顾总结。
DevOps平台设计
第一阶段的内容是关于平台设计。为什么会将平台设计放在第一阶段进行讲解？主要是这样考虑的，不管是做任何的工具或者产品之前，首先肯定是要解决某些痛点或者用户需求，这时候你就需要懂得平台除了呈现在外的功能，还需要理解平台设计的理念。其次当你懂得平台的设计思想，对于平台的理解会很大有帮助，因为这也是一个平台的灵魂所在，注入了设计者的大部分想法以及在实际应用中的经验，反而对于具体的实现技术我感觉现在慢慢已经不再是一个瓶颈，当你能够自己构建整个平台的知识体系之后，接下需要的就是资源、项目管理、推广就可以了。
我看到很多人介绍平台时都会以功能的方式去介绍平台的xxx功能之类的，个人感觉这种呈现方式并不太好，所以在讲这一部分时基本上全程中我都会尽量以场景的方式介绍为什么要有这个功能，以及功能使用的场景是怎么样的，能解决什么问题，产生什么价值，希望能帮助大家有更深入的理解功能背后的价值。
平台大概的一个蓝图如下：
平台第一个要解决的痛点是“从一个需求产生到发布上线全链路的跟踪“。所以一开始我们设计之初便是从”需求->报告",后面实际应用过程中孵化出“计划”和“监控”这个阶段，其主要需要解决的是在“计划”阶段把我们项目的立项、团队章程等也纳入到平台中；而“监控”主要是由于平台在公司范围内使用之后从安全、审计的角度孵化出的新的阶段。
平台第二个需要考虑的是我们需要打造怎么样的平台去服务我们的业务团队，优化我们整体的交付速率。当时主要是从“理论、实践、工具”三个层面去考虑，如上图。具体我就不详细展开了，课程中都有讲过。
经过我们与业务团队、领导、团队等多方面之后沟通交流之后，我们梳理出了下面这张图进行产品项目管理功能的设计：
上面这张图同时也融入了我之前学习敏捷时的理论，然后结合公司的现状做了一个改版，其主要设计思想来自于与敏捷项目管理框架，其中也引用了敏捷的3355、Kanban、UserStory等概念融入其中。这张图目前对应到平台主要是从团队章程到版本发布这一段。
对于这张图当时我讲的思路还是满清晰的，因为对于这一块感觉还是比较熟悉的，唯一的不足是当时举的例子是以DevOps平台的开发作为一个例子，可能这块对于没有做过平台开发的人会听起来有些跟不上，而且也没有太细致的去展开讲解每一个阶段，但是也把整个项目流程以及与平台之间的交互讲清楚了。
DevOps平台介绍
第二阶段，主要讲的内容是平台的一些功能介绍，这块当时没有讲太多功能方面的交互，因为平台还没开放，所以当时是以云效、TAPD做的例子进行演示，然后结合我自己画的一些线框图进行讲解，当时讲的也比较快，因为大部分同学应该都用过类似的平台，加上有上一阶段的平台设计课程作为基础，大家理解起来也更加容易一些，基本上对于功能也比较容易能Get到点。
这里当时是以一个用户管理作为例子，然后在云效上进行了一些演示，从需求拆分成任务，然后如何做测试跟踪之类的。其实这块东西业界真的已经做的非常成熟了，相关产品也蛮多的，现在回头想想好像这些功能十年前自己就用过，感觉对于项目管理平台，好像最近这些年都没有看到一些比较有创意新设计。
开发计划
这个阶段其实就是主要带大家分析了一下，如何根据前面我们的理论来做DevOps平台的版本发布计划、如何拆分我们的需求、如何排列用户故事的优先级、如何做版本的发布等，主要讲的是用户故事地图。
首先梳理出我们系统的一个主干路径，也就是我们的横坐标（黄色部分）。然后根据主干进行头脑风暴和故事拆分的方法进行细化，然后在根据细化的内容排列优先级，从上至下移动我们的卡片。最终就生出了我们的用户故事地图，然后根据用户故事地图得到我们的版本发布计划，再根据APMF框架进行我们发布的管理。
这里有一点当时忘记提的是，虽然我们梳理出了Release Backlog但是不要误以为这个就是一尘不变的，实际情况是每次作完一个Release x 之后所有的功能又需要重新按照价值优先级进行排列，只是第二次我们回顾用户故事地图时就不会像第一次那样讨论太多的细节，更多的是根据以前版本迭代的速率来决定下一个版本需要做作少用户故事，然后适当调整我们的故事卡片优先级即可。
开发计划还有一部分内容是讲解了我们的框架的选型，其中接口测试、在线思维导图、代码覆盖率都是来自于开源组织的项目，二次开发整合到平台之中，这部分的话在课程中也单独介绍了每一款开源平台的底层原理分析、源码解析、二次开发方法等。
项目开发主要是我自己写的一个小工程跟大家一起进行代码的分析。整体讲下来给我的感觉是可能大家对于项目开发这一块不太熟悉，所以提的问题也比较少，也或许是我讲的太快了。
在线思维导图
在线思维导图当时讲的是基于滴滴的AgileTC开源项目进行讲解的，关于这块讲的就比较细了，首先在自己阿里云主机搭建环境给大家体验，其次对于Xmind、AgileTC的原理分析、代码讲解也基本前前后后讲了一个遍，包括多人协作的WebSocket代码等，都进行了详细的分析。
讲这块内容时还进行了拓展讲解，比如如何通过代码进行自动化更新节点执行情况，如何将节点内容转化为平台中的表格用例，然后在将用例转化为自动化脚本，这块讲的还是比较满意的。
自动化测试
自动化测试当时主要是基于MeterSphere进行讲解了它的执行原理，二次开发与平台整合的方法这方面的经验分享，这块由于代码量太大了，所以在备课时我的想法时先讲个MVP把从用例保存到执行这条链路讲清楚，其他相关的技术以文档的方式提供给大家，现在回想起来应该是没错的。
不过也有一些不足的是，在讲自动化测试的时候本来还有另一部分是我想讲的，如何运行通过代码编写的用例，然后与平台进行结合的，但是由于流水线那块的代码我没有写MVP，所以这块就没有给大家演示，只讲了一个思路，现在回想起来可能大家对于这部分内容会不太好理解，到时候后面有空了我在以文档的形式补给大家吧，这里对各位热心来听我讲课的VIP学员说声sorry。
Nginx
nginx这块其实在我们整个DevOps平台中使用的还是蛮广泛的，用的也比较多，主要是做多个平台页面的管理、缓存、负载均衡、高可用等，然后对于测试来说可能nginx了解的并不会太深入，但是如果需要整合多个开源项目的时候那就离不开nginx的各种配置，所以这块当时我也是尽量举例说明其作用。并且也讲解了如何通过开源项目独立部署前端来提高性能，解决session等问题，希望大家能有所收获。
最后给大家演示了一下关于nginx高可用的搭建方案，以及演示运行时主机异常虚拟IP自动漂移到备份机器，让我们平台服务在异常情况达到高可用。
定时任务
这块内容当时讲的比较快，因为相对而言这块虽然难，但是比较通用、稳定，而且一般情况下也不需要进行二次开发，所以当时我给大家讲解的时候很快就过了，并且把通用的定时任务框架代码发给大家，基本上能用起来就行。
这里唯一需要注意的点是如何通过JobData做扩展我展开讲解了一下，其实利用定时任务可以做的事情蛮多的，比如自动化测试、数据库的备份等，基本上任何你想定时做的事情都可以通过quartz来完成。
流水线
流水线主要是构建、部署、测试、自定义任务的串联执行。这部分内容结合项目管理一起穿插的讲的，因为项目管理和流水线之前会有一些交互。当时举的应用场景应该是我们创建一个迭代，研发提测，测试准备开始执行测试时是可以自动配置我们流水线的触发的，达到自动化构建、部署、测试，输出报告，这样能反馈出我们的一个提测质量，如果未达到质量红线，可以走人工卡点打回，并产生记录，以此来提供快速反馈，提高提测质量和环境准备时间等。
测试覆盖率
主要从两个角度进行分析“需求覆盖”、“代码覆盖”。
需求覆盖统计的方法就如我们前面讲解的，我们会将需求拆分成用户故事的形式，然后在建立关联的开发任务、测试任务等，那么我们可以通过平台自动计算每一个用户故事是否都已经被与之关联的测试用例覆盖过，如果覆盖了，我们则任务这个需求“被测试过”，证明所有的需求都被测试验证过。
代码覆盖主要是讲解了JaCoCo的使用，然后结合开源Super-JaCoCo框架进行了代码的分析。然后以GitHub作为例子进行演示代码覆盖率的两种方式“人工测试”、“自动化测试”。
