敏捷研发—前端DevOps流水线实践

Tech 导读 本文介绍了如何将DevOps理念应用于前端开发的实践指南。从前端开发的背景现状及问题分析入手，详细介绍了前端DevOps中的流水线设计、需求管理、代码构建、测试部署、性能检测等方面的实践方法和工具，并结合案例分析和实践建议，帮助读者深入理解和掌握前端DevOps的核心概念和实践技能。 01

背景现状

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了

软件开发从传统的瀑布流方式到敏捷开发，将软件交付过程中开发和测试形成快速的迭代交付，但在软件交付客户之前或者使用过程中，还包括集成、部署、运维等环节需要进一步优化交付效率。因此DevOps的产生将敏捷的相关理念扩展到运维侧，从而将产品、设计、开发、测试、运维团队更紧密的结合在一起。而从交付给客户产品视角看，前端研发通常又是在整个产品设计开发链条的最终节点，意味着前端团队受到上游变更的影响是最大的，并且从经营理念效率出发，提升前端交付效率是至关重要的。那么如何提升交付效率呢，主要面临以下问题：

交付效率：

1. 敏态需求增加，即迭代性工作增加：软件开发从传统的瀑布流方式到敏捷开发，再到现在对敏捷开发提出了更高的要求。近些年项目的迭代性需求不断递增，这就要求前端开发者能够具备从开发到测试并且快速发布上线的能力，也需要团队完成由稳态到敏态的转变。
2. 前端研发效能瓶颈，达成双周交付面临挑战：敏捷迭代过程中，研发周期缩减并行需求增加，研发团队难以做到开发到测试和上线的过程中，全方位保证代码的高质量输出。
3. 研发过程中不必要的浪费降低交付效率：重复劳动、过度沟通、环节等待、通知不及时等。

质量&体验：

1. 质量安全把控不到位：研发团队大多关注代码和架构，对于项目如何能在生产环境稳定运行，需要考虑哪些安全性和可持续性的因素并不是很了解。
2. 研发流程标准不同，协同开发容易出错：开发者的编码风格不同，提测上线的流程不一致，关键流程环节的疏漏，风险行为难以约束，导致上线事故率增加。
3. 不同种类的应用服务的部署方式不一致：涉及到一些应用系统的调整、部署、扩展等，需要从新熟悉应用部署和构建环境的使用，使团队对发布没有信心。新的服务或者应用的构建，很难快速上线，被卡在了生产环境部署阶段。

02

问题分析

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。从设计稿出发，提升页面搭建效率，亟需解决的核心问题有：

下图是团队之前的开发流程，黄色为关键流程，绿色为必备环节。

图1 项目开发流程图

各个流程环节逐一分析：

图2 流程环节审核表

通过对这些问题和各个团队的反馈深入分析，发现其中最大的瓶颈在于研发协作之间的沟通壁垒、流程环节的疏漏和质量把控的不到位，而这些又是解决大多数问题的前提。

经过调研，发现DevOps恰恰是为这些问题而生，打造高效的交付流程成为破局的关键。

03

DevOps流水线引入

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。DevOps流水线简介：

1. DevOps流水线简介： DevOps流水线聚焦于将项目的需求、开发、测试、部署和运营统一起来，基于整个组织的协作和应用架构的优化来实现敏捷开发、持续交付和应用运营的无缝集成。
2. DevOps流水线与前端开发 定位：将前端业务中多且复杂的构建流程进行整合，使其成为一条可以覆盖前端业务场景的流水线，为前端开发者提供服务。 使命：减少开发者在复杂构建流程中所消耗的时间和精力，整体提高前端开发者效率。

04

DevOps流水线设计

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

4.1 架构设计

行云流水线采用了平台化管理+原子化设计+自定义开发模式，平台提供基础服务，能力可以通过原子化形式和自定义开发模式无限扩展，即兼顾了平台的稳定性，又大大减低了现有工具平台的接入成本。既有工具平台可独立对用户提供服务，也可以通过标准化方式输出插件化原子能力，作为持续交付平台的一环，纳入软件交付流程中，实现互利共赢、完美对接，减少重复建设，共建平台。

图3 DevOps架构设计图

行云流水线提供了良好的环境基础和丰富的原子准备，使构建自动化流水线时更加的方便快捷，也大大提升了团队的开发时间。团队的前端DevOps流水线即是基于行云流水线搭建。

4.2 流程设计

下图团队设计的前端DevOps自动化流水线，目的是打破开发、测试、产品、运营等不同岗位人员的沟通壁垒，让研发团队人员同时具备不同研发环节的能力，从而实现项目研发全流程的无缝集成。

图4 DevOps全流程设计图

前端DevOps流水线赋予的能力：

1. 项目流程管理的全局视角： 将整个项目研发周期拆解为：需求阶段、开发阶段、测试阶段、预上线和发布上线。每个阶段以流程节点串联的方式自动化运行，同时以行云卡片作为媒介显示当前所处的流程阶段。
2. 精细化的代码质量和风险管控： 通过实现代码和需求的关联，设计了更细粒度的质量卡点和风险管控策略。在关键节点约束研发操作行为，设置流程卡点并制定不同的质量检测机制，以便在早期的质量预防、中期的风险发现和后期的问题复盘都可以很大程度上减少成本投入。
3. 自动化的流程触发和行云卡片流转： 通过约定式代码提交，自动触发测试流程和上线流程，解放研发在流程流转中的额外操作和关注耗时。同时，行云卡片会伴随着项目阶段的变更自动流转，用于更精准的统计不同阶段的投入成本。并且，高度的自动化流程也为项目带来更高的品质和稳定性。
4. 即时的消息触达和流程提醒： 关键流程节点达成，会通过咚咚和邮件的方式即时同步给相关人员，进一步降低项目研发过程中的沟通成本，消息信息也可作为备忘代办和存档记录，时刻关注流程中的关键节点。

05

实践过程

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

整体的实践过程分为：

1. 需求阶段：制定工作流->需求创建->评审约束->关联代码分支。
2. 开发阶段：vscode可视化搭建（模板、调试、提测、预上线）。
3. 测试阶段：代码比对->编译打包->图片压缩->发布测试->性能检测->咚咚邮件通知。
4. 上线阶段：代码评审->代码合并->代码比对->编译打包->走查检测->图片压缩->JDOS部署->性能检测->咚咚邮件通知->回归测试->发布上线->行云验收。

5.1 需求阶段

图5 工作流程配置图

行云团队空间设置里，将工作流设置为阶段串联且不可跳过阶段和回撤，这样的好处是便于约束研发流程的各个阶段逐一流转，并有效地计算各阶段的投入成本。

图6 评审约束流程图

图7 评审约束实践图

为了防止员工私自承接确认需求，规范了评审流程，设置了评审约束。需求来源为业务和产品的需求必须经过项目管理者，在需求评审阶段评审通过后才能进入到后续的开发阶段，并可记录详细的评审信息。

图8 流程卡点-关联代码分支设置图

为了达到精细化的代码质量和风险管控，规定需求须和代码分支做关联，因此在工作流的开发阶段前置校验中设置了“检测关联代码分支”的流程卡点。

图9 流程卡点-关联代码分支演示图

工作流转到开发阶段，未关联代码分支会进行弹窗提示去关联代码分支，不关联将无法进入开发阶段。

图10 流程卡点-关联代码分支通过演示图

5.2 开发阶段

关联代码分支后，项目正式进入到开发阶段。

图11 VSCode插件界面图

VSCode代码编辑器插件，集成了模板，调试，提测，预发布等功能。让前端开发者更关注代码实现而简化项目初始化和项目进程流转。

图12 流水线触发设置图

可以通过此插件直接触发提测流水线和预发布流水线，也可以通过流水线的Coding代码约定式提交触发相应的流程。如上图所示，提交关键词“发布提测”触发提测流水线，进入到测试阶段。

5.3 测试阶段

图13 流水线测试阶段流程图

触发提测流水线后，流水线中的功能（代码差异比对、编译打包、图片压缩、上传测试页面、性能检测等）会自动执行，执行成功后会给相关人员发送咚咚提醒和邮件通知。

图14 咚咚提醒图

5.4 上线阶段

当测试通过需要上线时，团队制定了一个预上线的流程，目的是作为上线前的最后一次回归测试和质量风险管控。

1. 触发预上线流水线

图15 流水线代码提交触发设置图

与提测流程一样，可以在VSCode点击预发布按钮触发预上线流水线，也可以通过Coding提交关键词“发布预上线”来触发。

2. .分支代码合并

图16 流水线分支代码合并流程图

触发预上线流水线后，会自动执行分支代码合并主干的操作。因为之后的上线是主干上线，所以分支合并主干的操作具有关键必要性。

注意：未经过评审通过，分支合并将会失败，咚咚邮件会提示进行代码评审。

3. 代码评审

为进一步提高代码质量，降低潜在风险，在Coding平台制定了评审策略，只有代码评审通过才可以进行合并主干的操作，如下图所配置。

图17 Coding评审策略配置图

当分支代码没有进行评审时，评审人员会收到代码评审的咚咚和邮件通知，以此提高代码质量的管控，进一步降低沟通成本。

图18 评审人员收到的咚咚通知图

图19 评审人员收到的邮件通知图

图20 代码评审信息界面图

4. 评审通过自动合并主干

采用Coding系统的自动合并主干策略，规避人工合并带来的不确定性风险错误，如下图所示。

图21 评审完成界面

5. 自动触发预上线部署流水线

为避免评审过程中的等待时间浪费，当评审通过分支合并成功后，自动触发预上线部署的流水线。

此自动化触发机制来源于流水线的触发设置，如下图所示。

图22 流水线触发机制图

6. 自动执行预上线部署流程

预上线部署流程分为两个阶段串联：

图23 阶一流程图

图24 阶段二流程图

阶段一进行编译打包后，设置了代码自测（CheckList）的流程卡点，目的是提醒前端开发者最后检查一些风险事项，并确认提交，如下图所示。

图25 checklist检测页面图

全部勾选确认后，会自动执行预上线部署流程的阶段二（JDOS部署），并推送咚咚通知，如下图所示。

图26 部署开始通知图

7. JDOS部署和性能安全检测

图27 JDOS部署流程图

预上线部署流水线已经打通了JDOS的构建部署功能，并加入了Scan性能检测和烛龙安全扫描，为预上线的页面进行全方位的质量风险把控。

8. 回归测试并发布上线

预上线部署流程完成后，项目相关人员会收到咚咚邮件通知。

图28 流水线完成后咚咚通知图

图29 流水线完成后邮件通知图

现在，项目人员可以打开预发机器提供的链接，进行全回归测试。测试无误后，前往JDOS平台点击“上线申请”即可发布上线。

9. 上线完成发起验收

至此，整个项目研发流程结束并发起行云卡片验收。

06

总结

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

本次的敏捷研发系列，介绍了前端DevOps流水线的全流程实践，目的是提高交付效率和质量，解决前端研发中存在的问题。在梳理了需求评审、代码开发、测试和发布等环节的瓶颈和难点后，提出了采用DevOps流水线的解决方案。并详细介绍了实践过程，包括需求阶段、开发阶段、测试阶段和上线阶段的流程和操作，对提高团队协作效率和提升交付质量具有一定的指导意义。