网页设计师在什么公司工作seo怎么搞

导语

优维低代码技术专栏，是一个全新的、技术为主的专栏，由优维技术委员会成员执笔，基于优维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）

• 版本限制

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

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

• 实际版本

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

依赖分析提示

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

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

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

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

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

新增依赖

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

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

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

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

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

编辑依赖

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

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

更新依赖

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

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

2.8 版本信息

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

正如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 确认变更

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

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

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