公司网站的建设与运营管理制度,建设一个网站的方法,seo搜索引擎优化期末考试,哈尔滨网站建设推荐导语
优维低代码技术专栏#xff0c;是一个全新的、技术为主的专栏#xff0c;由优维技术委员会成员执笔#xff0c;基于优维7年低代码技术研发及运维成果#xff0c;主要介绍低代码相关的技术原理及架构逻辑#xff0c;目的是给广大运维人提供一个技术交流与学习的平台。… 导语
优维低代码技术专栏是一个全新的、技术为主的专栏由优维技术委员会成员执笔基于优维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中所说您应该和这些用户沟通确保他们的修改是处于完成状态、可被发布的。
确认后将进行打包稍等片刻您就可以在发布历史中看到您的打包记录。
