[发明专利]一种基于Gitlab CI的微前端构建方法

说明书

本发明公开了一种基于Gitlab CI的微前端构建方法，开发人员以feat或hotfix类型分支向release、master、stable_x等生产分支发起MR时，平台会自动新建一个开发版，命名规则为dev_${sourceBranch}‑${mrID}，等待测试人员合并后会让开发者所对应使用的生产分支产生新的Commit，此时平台会自动创建一个生产版，命名规则为${type}_${year}.${month}.${ID}。本发明实现了微应用版本的自动化构建，自动进行环境搭建和应用部署，减少操作人员负担和人工部署出错的概率，避免操作构建部署失败。

技术领域

本发明涉及一种基于Gitlab CI 的微前端构建方法，属于web应用技术领域。

背景技术

当下web应用中，大多都采用了前后端分离模式，大型前端应用越来越多，应用的前端代码量变得越来越大且存储于单个仓库里，通常开发和维护人员又分布在不同业务组，导致多人协作开发和维护困难。另外各业务系统依赖关系不明，无法按需打包，导致每次上线都要全量打包，打包时间过长的问题越发突出。

微前端是与多个可以独立发布功能的团队一起构建现代化web应用程序的技术、策略和方法，将庞大的单应用分割成更小、更易于管理的部分，然后明确它们之间的依赖关系。技术选型、代码库、团队，以及发布过程都应该能够相互独立地操作和进化，而不需要过度的协调。微前端拆分后，又会导致开发调试、运维部署的复杂度大幅增加，项目越大，微应用越多，版本管理就又成了大问题。如何高效管理微应用版本是目前的普遍问题。

随着国家数字化转型进程越来越深入，web应用在国内应用市场越来越普及。市面上的web应用随着需求的增加和自身迭代也越发变得丰富庞大。但是市面上很多web应用是多模块的单体应用，模块开发过程中每次版本部署都会全量构建打包，随着项目变大，这些开发工作之外的时间成本相应增加；另外代码合并冲突、版本管理等工作往往会浪费很多时间和人力成本。项目越大、维护团队越多问题越突出。

单体大应用中如果有某个模块需要迭代升级，现有功能无法满足需求了，对应需要更高版本的依赖，而其他模块择不能随便更改依赖，导致需求无法交付或改动牵扯更多兼容问题出来，使得开发工作无法有效推进甚至重构web应用。因此单体web应用越大在灵活性、拓展性、可靠性等方面越脆弱。单体web应用的复杂结构导致日常维护和迭代的困难越来越突出。

当下有不少企业引入微前端架构，随着应用拆分，带来了很多好处，如独立部署、增量迁移、团队自治、松耦合代码等，但是随着微应用变多、发布频繁，环境搭建和版本管理的问题则越发需要有效的解决。目前市面上大多数微前端架构只提供了运行时的方案，还没有提供调试、部署和运维微前端的整体方案。对于新的架构，需要有新的管理和部署运维方式。

发明内容

发明目的：为了克服现有技术中存在的不足，本发明提供一种基于Gitlab CI 的微前端构建方法，本发明实现了微应用的自动化构建，自动进行环境搭建和应用部署，减少操作人员负担和人工部署出错的概率，避免操作构建部署失败。

技术方案：为实现上述目的，本发明采用的技术方案为：

一种基于Gitlab CI 的微前端构建方法，包括以下步骤：

步骤1，开发人员以feat 或 hotfix类型分支向release、master、stable_x生产分支发起MR时，平台会自动新建一个开发版，命名规则为 dev_${sourceBranch}-${mrID}，其中，feat表示功能分支，hotfix表示缺陷修复分支，release表示集成分支，master表示生产分支，stable_x表示稳定分支，MR表示发起合并分支请求，dev表示开发分支，dev_${sourceBranch}-${mrID} 表示源分支为 sourceBranch、MR为 mrID 的开发版本，sourceBranch表示源分支，mrID 表示开发版本号；