优维低代码实践:打包发布

导语

优维低代码技术专栏,是一个全新的、技术为主的专栏,由优维技术委员会成员执笔,基于优维7年低代码技术研发及运维成果,主要介绍低代码相关的技术原理及架构逻辑,目的是给广大运维人提供一个技术交流与学习的平台。


优维低代码实践连载第24期

《打包发布》

一、为什么需要打包

通常,我们可以通过点击【构建并推送】,把微应用推送到开发环境。这样的一键推送非常方便,但同时也存在缺点:

  • 缺乏可控性,可能会将非期望的变更推送过去;

  • 无法区分开发和生产环境,如果加入测试环节,我们还需要区分测试环境;

  • 缺少版本管理,对测试不友好。

因此,除了【构建并推送】,Visual Builder 还支持将微应用进行打包,形成具有版本号的制品,以适应高阶的测试和生产需求。

二、如何进行打包

2.1 功能入口

优维低代码实践:打包发布_第1张图片

独立打包

也叫standalone模式,打出来的制品名称格式为 xxx-standalone-NA,它的特点是:

  • 将微应用的配置(storyboard)以及所依赖的一切前端构件、框架代码都打包进制品中,因此它可以独立安装部署;

  • 各微应用之间互相独立,互不干扰;

  • 运行环境需要enterprise发行版6.11或以上。

普通打包

区别于standalone模式,打出来的制品名称格式为 xxx-NA,它的特点是:

  • 仅将微应用的配置(storyboard)打包进制品中,微应用的运行依赖于运行环境中所部署的框架代码和构件;

  • 各微应用共用一套框架代码和构件,互相耦合;

  • 运行环境无版本要求(enterprise发行版6.11以上也可以兼容运行)。

2.2 修改统计

优维低代码实践:打包发布_第2张图片

在这里,你可以看到在上一次打包发布以后,都有哪些用户修改过编排。

你应该和这些用户沟通,确保他们的修改是处于完成状态、可被发布的。

2.3 版本对比

优维低代码实践:打包发布_第3张图片

提供了类似于git diff的方式来查看本次修改的内容,帮助用户进行变更检查。

2.4 静态检查

优维低代码实践:打包发布_第4张图片

通过静态语法分析,为编排提供一些修改建议。包括但不限于:

  • 不符合最佳实践的编排方式

  • 多余的编排配置

  • 合理化建议

您可以根据问题列表来对编排进行改进,但这些问题并不会影响微应用的实际功能。

2.5 性能检查(可选功能)

优维低代码实践:打包发布_第5张图片

我们会统计您的微应用各个页面的加载耗时,并将高于设定阈值(默认2.5s)的页面列出。

性能检查是一个可选功能,默认不会开启。

2.6 函数检查

优维低代码实践:打包发布_第6张图片

如果您在编排里使用了函数,那么打包时将进行对函数进行单元测试,提供测试结果和覆盖率。

2.7 依赖检查

微应用的运行,依赖于框架代码以及构件,因此,我们需要维护正确的依赖信息,才能将微应用运行所需要的依赖打进制品包内。

优维低代码实践:打包发布_第7张图片

依赖信息说明

  • 依赖组件

依赖的组件名称,包括各类构件(xxx-NB)、框架代码(brick_next)等。

  • 依赖来源

直接依赖,即直接添加的依赖。间接依赖,指那些不是直接添加,而是通过依赖的依赖而来的。例如:某个微应用的运行依赖构件 agile-NB ,而 agile-NB 又依赖框架代码 brick_next 的特定版本,那么 brick_next 就是一个间接依赖。(微应用 -> agile-NB -> brick_next)

优维低代码实践:打包发布_第8张图片

优维低代码实践:打包发布_第9张图片

  • 版本限制

限制某个依赖组件的版本范围。版本限制的写法参考了semver的规范,常用写法有:^1.1.0 表示 ≥1.1.0 且<2.0.0,* 表示任意版本均可。可以通过【新增依赖】和【编辑依赖】来设置版本限制。

在普通打包的情况下,微应用的部署会检查运行环境的框架代码、构件等组件是否满足依赖里的版本限制,不满足的话将会安装失败。

  • 实际版本

仅独立打包有效,表示依赖组件被打包到制品内的实际版本。如果缺少实际版本信息,那么打包时依赖组件将不会被打进制品内。【新增依赖】、【编辑依赖】和【更新依赖】时都会检查并分析组件之间的依赖关系,获取满足版本限制的最新版本,以此作为实际版本。

依赖分析提示

此步骤中,Visual Builder会检查编排内容,分析出需要哪些依赖并给出报错(红色)和警告(黄色)提示,包括:缺少依赖声明、缺少实际版本、未使用的依赖。

在提示信息最后都有快速操作按钮,用户点击按钮可以自动补充更新依赖信息。

  • 缺少依赖声明:Visual Builder分析出编排里使用了前端组件但未纳入依赖,打包时将不会纳入这些组件。

  • 缺少实际版本:依赖里的某个组件未获取实际版本,打包时将不会纳入这些组件。

  • 未使用的依赖:Visual Builder分析出编排里未使用前端组件但却纳入依赖,去掉这些依赖可以减少打包的制品体积。

新增依赖

优维低代码实践:打包发布_第10张图片

  • 首先填入依赖组件的名称。

  • 接着选择某个版本作为实际版本,又或者留空,让后台自动分析。

  • 最后一列是依赖组件的版本限制。对于独立打包,通常情况下,我们设置版本限制为“*”即可(表示满足任意版本均可)。

对于独立打包来说,Visual Builder会依据上面的选择,获取用户指定的版本,或者获取满足依赖限制的最新版本作为实际版本。

对于普通打包来说,依赖组件不会打进制品,版本限制仅用作安装时的依赖检查。所以我们可能需要设置适当的版本限制,以保证构件的版本足够新,能够包含微应用所需要的特性。

编辑依赖

仅修改组件的版本限制。如果需要修改组件的实际版本,请点击更新按钮。

Visual Builder会判断当前实际版本是否满足版本限制,不满足时会重新分析组件之间的依赖并获取最新版本作为实际版本。

更新依赖

  • 更新到指定版本:指定某个版本来作为实际版本。

  • 更新到最新版本:Visual Builder自动分析组件之间的依赖关系,重新获取组件的最新版本作为实际版本。

2.8 版本信息

优维低代码实践:打包发布_第11张图片

选择此次打包是新特性还是问题修复,您也可以手动填写版本。

正如2.7中所说,Visual Builder参考了 semver 语义化版本规范,采用了三段式的版本号。拿 3.1.2 作为例子:

  • 第一位为MAJOR,主版本号,表示大版本升级,不同大版本之间可能是不兼容的。

  • 第二位为MINOR,次版本号,表示小版本升级,不同次版本之间必须是兼容的。通常次版本号代表新特性的增加。

  • 第三位为PATCH,修订号,表示bug的修复。修订号不会影响到特性,仅仅是修复已知bug。

因此,选择新特性,MINOR会自动进位,例如:3.1.2 -> 3.2.0。选择问题修复,PATCH会自动进位,例如:3.1.2 -> 3.1.3。

2.9 确认变更

填写好版本信息以后,点击完成,有可能会弹出以下提示:

优维低代码实践:打包发布_第12张图片

正如2.2中所说,您应该和这些用户沟通,确保他们的修改是处于完成状态、可被发布的。

确认后将进行打包,稍等片刻,您就可以在发布历史中看到您的打包记录。

你可能感兴趣的:(低代码,低代码技术,低代码开发平台)