RDE - 一种基于Docker的前端生态集成解决方案

栏目: 编程工具 · 发布时间: 4年前

内容简介:RDE诞生的背景是,我们发现前端工程目前存在以下问题:如果业务中有大量工程,就会造成人力浪费与推进改造效率低下等问题;RDE通过重构前端工程结构,给出一套可维护的脚手架方案,实现业务与工程基础设施的分离、基础设施可持续升级维护、进一步提升业务开发者的开发体验;对原工程结构,按照功能进行拆分为3部分:
易于维护的前端研发架构复制代码

RDE诞生的背景是,我们发现前端工程目前存在以下问题:

  • 工程的开发与维护都是以工程为单位进行管理,每个工程都在重复开发基础设施

  • 脚手架都只负责初始化工程,只能保持在创建时一致,后续维护靠业务开发者自己重复维护

如果业务中有大量工程,就会造成人力浪费与推进改造效率低下等问题;RDE通过重构前端工程结构,给出一套可维护的脚手架方案,实现业务与工程基础设施的分离、基础设施可持续升级维护、进一步提升业务开发者的开发体验;

解决的问题

  • 开发业务时,先要从一堆与业务无关的(配置)文件中定位到页面文件,整体工程的感觉比较混乱

  • 每个工程重复建设基础设施,重复配置,如webpack基础配置,打点、sentry、mock搭建等

  • 每次升级依赖,如webpack、vue等、优化打包等,都需要推进每一个工程升级,效率低下

  • 很难同步多个工程的依赖规范,如统一使用echart,统一表单验证库等

  • 很难同步多个工程的开发规范,如一些norm术语,lint、serve等,再比如目录结构规范;可以降低跨工程开发成本

  • 工程文档维护比较困难,每个工程虽然可以放一个README,但是新人上手体验不好,并且README很容易由于没有及时维护而失效

实现方案

对原工程结构,按照功能进行拆分为3部分:

  • 工程基础设施:打包、开发、mock、lint、precommit校验、commit-msg校验、lint规则制定、基础依赖包等

  • 开发套件:多个工程复用的component、util、directive、mixin、decorator、filter、style、request方法等;

  • 业务应用:业务生产的工程

RDE充当着连接各部分的角色,提供方案,让这3部分的开发变得更简单;实现细节可以关注 wiki ,整体思路很简单,将工程拆分为一个app目录、一个template目录,app目录放业务,template目录放基础设施,app目录放在业务的git工程中,template目录发布在docker hub容器里,本地运行时,将二者在 docker 中进行聚合,然后运行;

RDE - 一种基于Docker的前端生态集成解决方案

核心功能 - CASE模型

RDC容器:用户自己封装维护,并发布在dockerhub上的的工程基础设施镜像,C代表Container

RDA应用:业务工程应用,A代表Application

RDS套件:在业务开发工作中,通用的不仅是组件,因此提出套件的概念,包括通用组件、方法、directive、mixin、decorators等

RDE工具: 整套方案的连接器,提供创建工程、开发运行、发布、生成IDE配置等功能

回顾前端发展进程,RDE可以作为集成汇总、组合所有服务的一个更通用的标准方案,让开发维护工程的粒度不再是工程,而可以根据自己实际需要,进行组合复用;如下图:

RDE - 一种基于Docker的前端生态集成解决方案

最佳实践

RDE打破了原有以单工程维护的业务架构,但是具体在业务中如何重组工程,拆分几个RDC,RDC如何定位,需要根据各自的业务讨论决定,不建议直接使用外部的RDC,每个团队(或部门)应该自己维护自己的RDC;即使是个人,假设你开发多个工程,个人也可以维护一个RDC,方便后续维护;目前RDC可以作为但不限于以下场景:

  • 作为业务工程的底层基建

  • 作为组件库、套件库的底层基建,可以包含发布、测试等基本功能,方便上层快速开发发布组件库

  • 可以作为Node端封装通用的配置或者逻辑部分

RDC的维护者需要配合RDE提供的render配置,创造出覆盖面更广的底层基建,需要抛弃单工程的开发的思维,结合上层各种应该用的场景进行开发维护;下面例举一下业务底层RDC的开发可能需要考虑的问题:

  • 是否封装了后台通用的菜单

  • 菜单如果是多种,是否可以让app层进行选择

  • 登陆、错误页、无权限页等通用场景是否需要封装进RDC

  • 是否制定路由规范,省去配置路由的麻烦

  • 制定团队lint规则

  • 是否包含mock、proxy等基础功能

  • 如果涉及发布、部署等命令,是否封装了这些操作

  • 如果需要使用单测,RDC是否提供了对应包的安装和配置

  • 一些最基础,最通用的包,是否安装, 如echart/momentjs/vue等

  • 如果使用了ts,一些最基本的d.ts文件的定义,是否已提供

  • 如果有样式规范,是否提供了最基本的样式以及对应的样式方法、mixins等,如BEM方法、常用的方法等

  • 是否提供了方便应用开发使用的webpack alias配置

  • 整个RDC哪些部分需要支持应用扩展,扩展规则如何制定

  • 是否提供了完善的文档,供应用开发者使用

  • 生态选型,版本升级维护,如未来的webpack升级,vue/react升级等

  • 打包性能优化

上手体验

安装依赖环境

$ docker pull node
复制代码

安装RDE

$ npm i -g rde

$ yarn global add rde // if using yarn
复制代码

创建工程

$ rde create
复制代码
  • 填写要创建的工程名

  • 选择创建类型为Application

  • 选择要创建的工程的框架

  • 为了体验,容器和容器版本选择默认即可

开始探索

创建成功后,可以开始探索了,先切换到工程目录后,发现生成了:

文件 类型 说明 IDE显示 GITIGNORE sync覆盖 RDA关注
app 目录 初始的业务代码目录 - -
template 目录 从镜像中拷贝出来的,供本地开发使用的配置文件及其他文件 - -
rda.config.js 文件 RDA配置文件 - -
.git 目录 生成了precommit钩子和commit-msg校验 - only hooks -
gitignore 文件 包括初始规则的文件 - -
.vscode/.idea 目录 编辑器初始配置文件 - -
.devcontainer 目录 提供给vscode-insiders体验的配置 - -
node_modules 目录 根据容器要求安装的node_modules - -
README.md 文件 自动生成的readme - -

其中这里我们要关注的只有app目录和rda.config.js,其他文件都是为了本地开发使用,从镜像中复制出来的,已经添加在gitignore中, 不允许修改的,具体解释如下:

  • IDE显示:在vscode或者webstorm中开发时,是否显示该目录

  • GITIGNORE: 默认已经加在gitignore中的规则

  • sync覆盖: 执行rde sync时会被覆盖的文件

  • RDA关注: 开发业务应用需要关注的文件

接下来执行:

$ rde clean
复制代码

会删除除了应用需要关注的目录外的所有文件;如果要还原,可以再执行

$ rde sync
复制代码

又还原出了所有的文件,sync可以再每次升级容器版本、误删除某些文件的情况下使用;

使用vscode或者webstorm打开工程,可以发现默认只能看到app, rda.config.js等几个文件,因为RDE已经帮你生成了初始配置,隐藏了不需要关注的文件; 另外,如果你使用的是vscode-insiders或者最新版的vscode(并且安装了remote插件),在使用rde clean后就可以进行开发了,直接打开container即可;由于vscode-insiders不是稳定版本,所以只作为测试体验功能使用,不推荐;

更多详情请参考官网文档与 github仓库


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

探索需求

探索需求

章柏幸、王媛媛、谢攀、杰拉尔德・温伯格、唐纳德・高斯 / 章柏幸、王媛媛、谢攀 / 清华大学出版社 / 2004-7-1 / 39.00元

本书将与您一起寻找"什么是客户真正想要的"这一问题的答案。 本书着眼于系统设计之前的需求过程,它是整个开发过程(如何设计人们想要的产品和系统)中最有挑战性的那部分。通过对一些需求分析中的常见误区和问题的分析和讨论,从和客户沟通开始,深入研究一些可能的需求,澄清用户和开发者期望值,最终给出了能够大幅度提高项目成功几率的一些建议方法。 本书由该领域内公认的两位作者合著,搜集了他们在大大小小......一起来看看 《探索需求》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

随机密码生成器
随机密码生成器

多种字符组合密码