关于javascript:🌟技术探索🌟借助-CI-CD-实现前端应用的快速回滚

背景

在 上一轮优化 里， 咱们通过优化一些构建工具和流程， 把构建耗时优化到了 4min 左右，整体公布耗时从 15min 优化到了 8 min 左右, 有较大晋升， 然而仍旧存在晋升空间。

通过一些思考与测试，给出技术计划，并落地到了 WMS 业务中， 成果如下：

与原流程相比之， 公布耗时由 8 min 升高到了 1 ～2 min 左右。

上面我次要介绍一下计划细节，总结革新过程中遇到的问题， 心愿对大家有所帮忙。

注释

整体方案设计

1. 现有架构

现有架构有余：

每次执行 jenkins 都要从新开始执行构建、打包操作，十分的耗时。Jenkins 没有留存打包后果，导致无奈做回滚等操作。

以后构建流程中存在大量有效且耗时的构建能够去掉，如应用 docker 打包了镜像，但对于该我的项目而言是无用的。

架构改良

CI/CD 前置打包

MR 之后， 会触发 CI, 执行构建工作，构建过程在 2 min 左右， 构建胜利之后， 会把对应的后果推送到对应的分支保存起来。

Jenkins 构建阶段， 间接从对应的分支取回打包后果， 推送到动态资源服务器，这个过程十分快， 1 分钟之内即可实现公布。

须要留神的是： 因为是在 gitlab 中构建的， 这时候会短少一些环境信息， 比方 CID。

WMS业务中并没有用这个参数做一些非凡的逻辑， 所以没有影响。 如果我的项目须要用到 CID， 则须要额定解决。

公布与回滚

公布流程间接公布通过 gitlab CICD打包出的后果分支，体现在 jenkins流程中，就相当于是仅仅复制了一份后果内容到指标动态服务器回滚操作间接打包 build-release分支的上一个 tag 即可。

uat、 release 公布之后， 资源会被打上 tag 保留在 gitlab 中， 一个 tag 对应一份资源，借助 lasg_tag 即可实现疾速回滚。

具体实现步骤

1. 批改 deploy.json 与 .gitlab-ci.yml

"project_dir_depth": 2, 
"project_name": "wmsuiv2",
"module_name": "static", 
"build": {
"commands": ["echo 'deploy websitestatic'"], 
"upload_static": {
  "static_dir": "dist", "enable_cdn": false
},
"docker_image": {
"base_image": "harbor.shopeemobile.com/shopee/nodejs-base:14",
"dependent_libraries_files": [],
"run_commands": ["pip install -U shopee-deploy-common"]
// ... 

// .gitlab-ci.yml

image: harbor.shopeemobile.com/shopee/nodejs-base:14

variables:
env: '${CI_COMMIT_REF_NAME}' ENV: '${CI_COMMIT_REF_NAME}'

stages:
build

build:
stage: build 
rules:
if: $CI_COMMIT_REF_NAME == 'uat' && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == null
if: $CI_COMMIT_REF_NAME == 'release' && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == null
if: $CI_COMMIT_REF_NAME =~ /version\/release-(.*)$/ && $CI_PIPELINE_SOURCE == 'web' variables:
GITLAB_URL: 'https://gitlab-ci-token:${CI_JOB_TOKEN}@git.garena.com/shopee/bg-logistics/tianlu/fe/wms-ui.git' GITLAB_W_URL: 'https://${USERNAME}:${PERSONAL_ACCESS_TOKEN}@git.garena.com/shopee/bg-logistics/tianlu/fe/wms-
ui.git' script:
echo "CI_COMMIT_BRANCH:${CI_COMMIT_BRANCH};CI_COMMIT_TAG:${CI_COMMIT_TAG}; CI_DEFAULT_BRANCH:${CI_DEFAULT_BRANCH};CI_MERGE_REQUEST_TARGET_BRANCH_NAME=${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}"
npm install --registry=https://npm.shopee.io
echo "[sys] npm install [finish]"
npm run build
echo "[sys] npm run build [finish]"
if [[ "$CI_COMMIT_REF_NAME" =~ ^version/release-.*$ ]]; then
TARGET_BRANCH="temp/build-staging"
else
TARGET_BRANCH="temp/build-${CI_COMMIT_REF_NAME}"
fi
git clone -b ${TARGET_BRANCH} ${GITLAB_URL}
cd wms-ui/
echo "TARGET_BRANCH:${TARGET_BRANCH}"
echo "CI_COMMIT_REF_NAME:${CI_COMMIT_REF_NAME}"
git config --global user.name "wms.frontend"
git config --global user.email "[email protected]"
rm -rf ./dist
cp -rf ../dist .
git add .
git commit -am "git ci push" -q
git push ${GITLAB_W_URL} ${TARGET_BRANCH}
echo "[sys] git push to ${TARGET_BRANCH} [successful]"
if [[ "$CI_COMMIT_REF_NAME" == "release" ]]; then
TAG="tag-$(date +%y%m%d-v%H%M)"
echo -e "[sys] tag name ${TAG}"
git tag ${TAG}
git push ${GITLAB_W_URL} ${TAG}
echo "[push succcessful]"
fi

这个过程实现之后， 后续的操作：

1. 创立对应的分支

以 test 分支为例， 从 test 分支 拉一个新分支： build-test, 用于寄存打包后果。

这个分支内，只保留三个文件/文件夹：deploy、dist、.gitignore， 其余内容全副删除。

其中，deploy是用于给jenkins读取构建脚本应用；

dist目录为gitlab CI/CD后续打包的产物；
.gitignore为须要排除提交的目录及文件；

特地留神：
.gitignore 中不能疏忽 /dist 。

我的项目设置中， 要把 reject unverified users 选项关掉， 否则会导致推送失败。

其余细节：

• 镜像必须放弃跟 jenkins 脚本配置一样
• 须要应用 gitlab-ci-token来在脚本命令中拉取代码Push 阶段是必须依赖于 build 阶段
  利用范畴为 uat，release，version/release-xxx分支，其中前两个为合代码时主动触发，版本分支须要人工在 CI/C -> pipeline -> 点 ‘run pipeline’按钮触发

跨账户提交步骤：

将专用账户 wms.frontend 退出到该我的项目，并设置为 maintainer. （专用账户申请地址： 链接， WMS 项目组 曾经申请，不必额定申请） 应用 wms.frontend登录，在集体账号的 edit profile 中的 Access Tokens创立一个 Personal Access Token，失去 username 和token。

将 username 和 token 存到对应我的项目的 CI/CD 下的 variables 中，这样就能够在 cicd 脚本中通过变量 ${username} 获取到验证的信息而后下面在git push前，须要将git config 账户配置成公共账户信息，这样就能够应用他的token进行提交操作了。

实现以上配置， MR 之后， 就会主动执行构建， 并推送后果。

到此， 第一步就实现了， 之后就是在 DMS 中创立公布工作。

与现有流程不同的只是抉择的构建分支不同。

以 test 为例，现有流程抉择的是 test 分支， 新流程须要抉择： temp/build-test 分支, 毕竟在这个过程中 ，jenkins 只是对 temp/build-test 分支中的文件做了一次拷贝， 并推送动态文件服务器中。

至此，革新就实现了。

最初须要揭示的是：

merge 之后，会有大概 2 分钟的构建耗时，如果此时立即去 jenkins 公布， 则可能公布的是旧的构建后果， 这尽管没有破坏性， 但与预期不符。

对应措施是：

增加 seatalk 音讯群告诉，构建实现之后，揭示相干公布人员， 实现公布。

兜底措施：

如果遇到极其状况导致 gitlab 无奈实现构建， 也能够改回原有的配置， 走原有流程。

操作步骤：

把 deploy.json 和 .gitlabyml 重置，合并到对应分支。
在 Jenkins 构建原始分支（test、uat、release）即可。

思考与延长

构建与公布之间存在时间差， 这个问题看时候能与 DMS 团队沟通， 凋谢一个音讯告诉能力， 主动实现这个过程，缩小对人的依赖。

增加机器人告诉的形式也不简单， 实现如下：

// ...
- >
sh -c "curl -i -X POST -H 'Content-Type: application/json' -d '{\"tag\":\"text\",\"text\":{\"content\": \" WMS-UI FE:${TAG}\"}}' https://openapi.seatalk.io/webhook/group/${groudId}"
- fi
// ...

总结

传统的公布与回滚，依赖一次构建， 本计划的外围思路是: 借助第三方存储，保留打包产物，以此缩小构建工夫。

相似的计划还有很多， 也不仅仅这一种解决形式，在此不做延长。

本篇被容就这么多， 心愿能给大家一些启发， 谢谢。

满腹经纶， 如果谬误， 还请斧正， 谢谢。