当程序员确认可以发布版本，在由运维人员发布成功之后，测试人员发现刚刚发布版本有问题时，严重的，则需要进行回滚操作了。

对于程序员以及领导来说，回滚只不过是线上业务出现问题的时候一句话而已，但是对于运维人员来说，回滚则是平时就要做好准备的事情，不仅要做好准备，更要有经过演练。

我就曾有过自以为脚本方面都是梳理完整了放进Jenkins里，突然一天领导那边说需要回滚一下子，我当然觉得没有问题咯，于是兴致勃勃的跑去进行了回滚的操作，最后却发现，压根儿就没有成功，这就非常尴尬啦，顿时就脸红脖子粗起来，脖子粗也没用呀，问题总还要解决，于是最后只得手动打包，进行了一次原始部署了。

因此，回滚是一件闲时准备，战时不慌的操作，非常重要了。

我这里提到的回滚，都是基于Jenkins来进行部署考虑的，通过我个人对Jenkins的理解，大致分有以下方法可供选择：

1，gitlab代码回滚。

由程序员先将Git的版本回退到上一个版本，然后再一次进行部署。就实现了上个版本回退。

但是这种情形很容易受到影响，如果过程中有其他人进行过提交，版本不容易定位，如果牵扯到一些数据库的问题，就更加复杂，极有可能出现一些无法控制的问题，因此这是一种十分不推荐也不可取的方式。但是据我了解到一些公司就曾采用过这种方式来进行回滚的操作，想起来也是十分让人难以理解的。

好了废话不多说，进入今天正题。

2，脚本方式回滚。

在Jenkins部署脚本当中加入git rev-parse HEAD命令记录每次发布的版本的唯一版本号，并将此记录在一个log文件里，如果需要回滚，则由脚本取出上一次发布的版本号（命令为：tail -n 2 version.log | head -n 1）进行版本的回退，而后在回退的基础上再发布即可。

这是一种非常保险，也绝对靠谱的一种方式了，非常非常推荐。

唯一的缺点，大概可能就是需要重新部署一次有点耗时间，对于某些高访问量（时间就是金钱）的线上业务来说，显得有点耽误工夫了。

具体的这种回滚方式的相关脚本以及思路的参考，我在另一篇文章当中已经写出，可以点击这里进行跳转浏览 (opens new window)。

3，war包回滚。

在每一次发布部署的同时，将每一个部署的（JAVA）war包按时间进行备份，然后再备份一个紧邻的上次发布的bak包，如果需要紧急回滚，则直接将上一个包替换当前包即可。由于一般回滚不会回滚到很久以前的版本，所以这里的备份包，保留五个即可，多余的利用脚本进行删除，避免了时间长占用空间过大的问题。

思路基本如上，我这里列出一个简单脚本仅供参考。

#!/bin/bash
#author:eryajf
#time:2018-7
source /etc/profile
mode=$1
project=$2
code_dir=/root/project/$project
tomcat_dir=/usr/local/tomcat_$project
ROOTWAR_dir=$tomcat_dir/WAR
bakdir=$tomcat_dir/bak_dir
MAVEN_CODE(){
   cd /root/project/$project
   mvn clean install -Dmaven.test.skip=true
   [ $? -ne 0 ] && echo -e '\033[31m[ error ] Failed to maven the code\033[0m' && exit 1
   [ -d $tomcat_dir/WAR ] && mkdir -p $tomcat_dir/WAR
   cp $code_dir/51fbadmin-web/target/ROOT.war $tomcat_dir/WAR
}
 
deploy()
{
   echo "MAVEN_CODE"
   MAVEN_CODE
   [ ! -d $bakdir ] && mkdir -p $bakdir
   echo "backup"
   [ -f $ROOTWAR_dir/ROOT.war ] && [ -f $tomcat_dir/webapps/ROOT.war ] && mv $tomcat_dir/webapps/ROOT.warbak $bakdir/ROOT_$(date +"%y%m%d%H%M%S").war
   mv $tomcat_dir/webapps/ROOT.{war,warbak}
   echo "stop tomcat_$project" && ps aux | grep "$tomcat_dir" | grep java | grep -v grep | awk '{print $2}' | xargs kill -9
   rm -rf $tomcat_dir/webapps/ROOT && mv $ROOTWAR_dir/ROOT.war $tomcat_dir/webapps
   echo "start tomcat_$project" && /bin/bash /usr/local/tomcat_$project/bin/startup.sh
}
 
rollback(){
   echo "stop tomcat_$project" && ps aux | grep "$tomcat_dir" | grep java | grep -v grep | awk '{print $2}' | xargs kill -9
   rm -f $tomcat_dir/webapps/ROOT.war && rm -rf $tomcat_dir/webapps/ROOT
   mv $tomcat_dir/webapps/ROOT.{warbak,war}
   echo "start tomcat_$project" && /bin/bash /usr/local/tomcat_$project/bin/startup.sh
}
 
case "$1" in
   'deploy')
        deploy
        ;;
   'rollback')
        rollback
        ;;
   *)
        echo "Usage: $0 {deploy | rollback}"
        exit 1
esac
exit 0

因为这个脚本是一个最后环节的，所以我简单说明一下：

1，脚本承接Jenkins处传递过来的两个参数，一个是mode的值，一个是project的值，mode决定是部署还是回滚，project则决定了是对哪个项目进行操作。 2，部署的时候，先将上次备份的bak包放进一个专门存放old包的目录下，将正在用的包备份成bak包，然后进行常规的部署。 3，如果回滚，则直接将bak还原回来，即达到回滚目的。

这种简洁高效，非常好用。只要在部署的时候将对应的包进行很好的安置，事情都会非常好处理的。当然了，还少一个定期清理目录下包数量的脚本，别急，您可以参考我的另外一篇文章：如何让不断增加的目录只保留五个文件？ (opens new window)

4，tag回滚。

这种回滚方案配置非常简单，而且实用性也非常强，已经在另外一篇文章中进行发布，如需浏览，可以点击跳转：Jenkins利用tag方式进行回滚！ (opens new window)