jenkins实现基于tag前端发布回滚

569 阅读3分钟

前言

前几篇文章实践了jenkins的搭建和前端部署。本文主要探索下,前端如何通过jenkins进行回滚操作。

公司在上线前,合并代码在主分支会打tag,那么每次打的这个版本号具体的有什么作用,不仅仅让每一次我们发布过的代码有记录存留,也能够方便一些其他的功能(比如回滚)。

本文基于标签进行回滚,主要两种方式进行实践:

  1. 通过tag进行reset重置回滚
  2. 基于构建产物tag标记进行回滚

1. 基于tag进行reset回滚

如何基于tag进行reset回滚,

主要流程如下:

  1. 选择回滚操作,是否是发布(deploy)还是回滚(rollback)
  2. 回滚需要选择tag
  3. 添加shell命令,通过git reset --hard $tag重置
  4. 打包发布到服务器

image.png

下面进行构建化参数过程配置:

1.1 添加mode选项

第一个参数mode:用于判断是构建还是回滚操作

image.png

1.2 添加pnpmInstall选项

第二个参数: 是否需要安装依赖

image.png

1.3 添加 Git Parameter 选项

第三个参数:选择分支 image.png

第四个参数:选择回滚版本tag

image.png

上述完成后,构建页面如下图所示:

image.png

1.4 修改shell内容

这一步需要通过上述添加的构建化参数,写shell脚本,主要就是判断是否是回滚,回滚重置提交到tag,再进行打包发布。

回滚脚本:

#!/bin/bash
if [ $mode == 'deploy' ]; then
if [ $pnpmInstall == 'true' ]; then
  echo "安装依赖包"
  rm -rf node_modules
  npm i -g pnpm
  pnpm i --registry=https://registry.npmmirror.com
else
  echo "跳过依赖包安装"
fi
  pnpm run build:test
else
echo "回滚代码"
 git reset --hard $tag
 pnpm run build:test
fi

1.5 操作效果

为master分支几个提交分别打上几个tag,如下所示:

image.png

1.5.1 发布

先进行正常发布:

image.png 打包后效果:

image.png

1.5.2 回滚

选择tagv1.0.1进行回滚

image.png

回滚完成后:

image.png

1.6 总结

通过此种打包方式缺点是每次回滚需要进行打包,浪费时间。保存上几次的构建产物,直接通过tag进行获取进行部署,就减少打包时间,进行快速回滚。

2. 基于构建产物tag标记进行回滚

主要流程如下:

  1. 每次发布成功后,建立以tag名称文件夹,将构建产物进行保存
  2. 需要回滚后,查找tag名称的文件夹,发布到服务器

2.1 保存构建产物

每次发布成功后,建立以 tag 名称为文件夹,将构建产物进行保存:

#!/bin/bash

# 获取当前分支名称
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
echo "当前分支: $BRANCH_NAME"

# 获取当前分支的最新标签
LATEST_TAG=$(git describe --tags $(git rev-list --tags --max-count=1 --branches=$BRANCH_NAME))
echo "最新标签: $LATEST_TAG"

# 建立以 tag 名称为文件夹,将构建产物进行保存
mkdir -p /path/to/artifacts/$LATEST_TAG
cp -r dist/* /path/to/artifacts/$LATEST_TAG
echo "构建产物已保存到 /path/to/artifacts/$LATEST_TAG"

2.2 回滚构建产物

需要回滚时,查找 tag 名称的文件夹,将其发布到服务器:

#!/bin/bash

if [ $mode == 'deploy' ]; then
  if [ $pnpmInstall == 'true' ]; then
    echo "安装依赖包"
    rm -rf node_modules
    npm i -g pnpm
    pnpm i --registry=https://registry.npmmirror.com
  else
    echo "跳过依赖包安装"
  fi
  pnpm run build:test
  
  # 保存构建产物
  BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
  LATEST_TAG=$(git describe --tags $(git rev-list --tags --max-count=1 --branches=$BRANCH_NAME))
  mkdir -p /path/to/artifacts/$LATEST_TAG
  cp -r dist/* /path/to/artifacts/$LATEST_TAG
  echo "构建产物已保存到 /path/to/artifacts/$LATEST_TAG"
  
else
  echo "回滚代码"
  cp -r /path/to/artifacts/$tag/* dist/
  echo "构建产物已从 /path/to/artifacts/$tag 回滚"
  pnpm run build:test
fi

2.3 操作效果

发布

正常发布时,构建产物会被保存到指定的文件夹中:

mkdir -p /path/to/artifacts/$LATEST_TAG
cp -r dist/* /path/to/artifacts/$LATEST_TAG

回滚

选择特定的 tag 进行回滚时,从保存的构建产物中复制文件到 dist 目录:

cp -r /path/to/artifacts/$tag/* dist/

2.4 总结

通过这种方式,每次发布成功后,保存构建产物,可以大大减少回滚的时间。回滚时,不需要重新打包,只需从保存的构建产物中获取对应版本的文件,快速发布到服务器。这种方法提高了回滚的效率,也减少了出错的可能性。

总结

最后总结一下,两种方式的优缺点:

  • 基于 tag 的 reset 回滚

    • 优点:直接基于 git 操作,流程简单明了。
    • 缺点:每次回滚需要重新打包,耗时较长。
  • 基于构建产物的 tag 标记回滚

    • 优点:回滚速度快,不需要重新打包。
    • 缺点:需要额外的存储空间来保存每次发布的构建产物。

根据项目的具体需求和资源情况,可以选择适合的回滚方式,提高发布和回滚的效率和稳定性。

如有错误,请指正O^O!


相关文章:

三分钟!快速解决Dockerhub镜像站无法访问问题!

Docker部署nginx发布前端项目

Nginx部署多项目详细总结

Docker部署Jenkins搭建前端构建环境