本文主要是介绍优维低代码实践：打包发布，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
导语
优维低代码技术专栏，是一个全新的、技术为主的专栏，由优维技术委员会成员执笔，基于优维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中所说，您应该和这些用户沟通，确保他们的修改是处于完成状态、可被发布的。
确认后将进行打包，稍等片刻，您就可以在发布历史中看到您的打包记录。
这篇关于优维低代码实践：打包发布的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
