前端项目的版本标记

前言

低代码平台在给客户方部署新环境时，大概涉及如下内容：

1. dev-webapp - 低代码开发时（在这里搭建APP）
2. deploy-webapp - 低代码运行时（搭建APP的运行环境）
3. admin-webapp - 低代码管理平台（用来统一管理多个deploy-webapp）
4. appZip - dev-webapp 搭建好的APP导出的zip包（在 admin-webapp 上传后，就可以在 deploy-webapp 里运行了）
5. service - 后端服务

上面涉及的内容里，前四项是与前端相关的。

我们需要确保每次给客户部署时，dev-webapp、deploy-webapp、admin-webapp 以及应用数据appZip 的版本一致，否则不一致的代码和数据混杂着，可想而知程序是大概率无法如期运行的。

运维人员在部署时拉取Docker镜像，可以通过镜像时间和 tag 来确定版本。但如果部署后项目运行遇到问题（或者很久后接到了帮客户修改一下bug的任务），这时候我们排查问题或修复bug，都需要或确定部署代码的版本、或找到当前版本的提交checkout修复问题。

这时如果在前端暴露一个 id 用来帮助前端人员快速定位问题/找到当时提交就很方便了。git commit id 似乎可以很好的完成这个任务。

目的

在项目打包时，把当前的 git commit id 混入到项目中，方便前端同学快速排查问题。

代码

github：vite-plugin-version-mark

npm：vite-plugin-version-mark

# 获取当前分支最新commit hash
git rev-parse HEAD

# 获取当前分支最新commit 短hash
git rev-parse --short HEAD

TODO

• 与数据（应用包）的版本对应：
  • 在打包时，把版本记录在zip包内。在admin-webapp上传应用包可以查看版本号。
  • 使用commitID作为版本唯一信息的话：如果在dev环境进行打包，在demo环境上传测试，那么zip包和admin/deploy的commitID是一定不一致的。如果要解决这个问题，就不能使用commitID作为版本号。
• 与后端的版本对应