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

本文主要是介绍优维低代码实践：打包发布，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

导语

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

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

《打包发布》

▽

一、为什么需要打包

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

缺乏可控性，可能会将非期望的变更推送过去；
无法区分开发和生产环境，如果加入测试环节，我们还需要区分测试环境；
缺少版本管理，对测试不友好。

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

二、如何进行打包

2.1 功能入口

独立打包

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

将微应用的配置（storyboard）以及所依赖的一切前端构件、框架代码都打包进制品中，因此它可以独立安装部署；
各微应用之间互相独立，互不干扰；
运行环境需要enterprise发行版6.11或以上。

普通打包

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

仅将微应用的配置（storyboard）打包进制品中，微应用的运行依赖于运行环境中所部署的框架代码和构件；
各微应用共用一套框架代码和构件，互相耦合；
运行环境无版本要求（enterprise发行版6.11以上也可以兼容运行）。

2.2 修改统计

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

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

2.3 版本对比

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

2.4 静态检查

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

不符合最佳实践的编排方式
多余的编排配置
合理化建议

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

2.5 性能检查（可选功能）

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

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

2.6 函数检查

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

2.7 依赖检查

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

依赖信息说明

依赖组件

依赖的组件名称，包括各类构件（xxx-NB）、框架代码（brick_next）等。

依赖来源

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