我正在参加「创意开发 投稿大赛」详情请看：掘金创意开发大赛来了！”
求个点赞过100
创意
-
公司目前使用的是
Jenkins来进行持续集成工作。同类型的还有TeamCity、CircleCI等等产品。 -
这些产品的定位都有一个特点：面向服务。
-
面向服务的确是优点，这也是他们广受好评之处，但是今天我想说的是：面向个人。
-
Jenkins我们主要是用在集成环境、正式环境等需要相对稳定且更新不频繁的服务上面。但是本地环境或者是开发测试环境有的时候需要频繁的迭代开发，这个时候再整一套Jenkins优点得不偿失了。所以在我们部门针对开发环境采取的是两种环境杂糅的方式并存的。作为开发我们更偏向于自己传包维护服务的。 -
自己发包就存在一个问题，每一次发包我们大致需要
- 本地打包
- 本地包传输到服务器
- 去服务器杀掉原进程并重启新服务
- 查看日志是否启动成功
- 验证功能是否正确
-
有的时候打包需要很长时间，比如下面
thingsboard的打包就需要很久。10分钟的时间就在那里等优点摸鱼的嫌疑，但是去干其他事情有点匆忙。
-
每一步都很简单，但是串联起来很有可能中间我们被其他事情打扰而中断。因为我就经常在这五步中突然被叫去干其他事，于是我痛定思痛就想用
Jenkins。使用过Jenkins的都知道无法并行运行任务。Jenkins只能一个项目一个项目的执行这点很难受，而且我只是想方便自己的定制化需求，如果使用Jenkins会有以下缺憾：- 执行效率低下。
- 公共部分无法做到个性化修改，比如我想打dev分支，但是
Jenkins设置的是master分支，每次改来改去也很麻烦。 - 出现异常情况还是需要登陆服务器查看详细日志(不如本地查看方便)。
- 对于个人来说，
Jenkins太笨重了。
-
种种原因使我放弃
Jenkins，最终我决定自己实现一套脚本代替我重复简单而又枯燥无味的工作流。
实现
功能设计
- 一开始我的想法很简单就是用脚本去执行打包命令，但是想要实现真正的自动化，仅仅打包命令是不行的，所以后来我加入了其他动作。
- 为了将功能做的更高级点，或者说方便自己针对项目进行概览，在上面的基础上加了些辅助功能。
选角(技术选型)
- 功能设计出来后就面临着技术选型，
Java作为我的第一大接触语言当然是我的首选，但是Java依赖于JDK,所以被我抛弃了。 - 再然后就想到目前比较火的
Python技术了。考察了下Python也都被部分Linux作为内嵌服务提供了，基于这点【我很中意你哦】。 - 当我开始打开【Python入学教程】之后发现我对
Python的了解完全是小白。加之目前只有想法没有实践所以Python被我临时的放弃了。 - 最终我选择了Linux的Shell来实现【自动化部署】的创意想法。
实践
判断项目
- 既然是自动化打包，就不能被我们本地正在开发的项目所打扰，所以第一步我也是选择了从git仓库clone项目到本地进行打包，这也是一切以仓库为准的原则。
if [ -d "$mainPath$projectName" ]
then
echo "[$mainPath$projectName] exists"
cd $mainPath$projectName
git checkout dev
git pull origin dev
git checkout $branchName
git merge dev
git pull origin $branchName
else
echo "[$mainPath$projectName] not exists"
git clone ${gitPath} -b $branchName "${mainPath}$projectName"
cd $mainPath$projectName
git checkout dev
git pull origin dev
git checkout $branchName
git merge dev
fi
- 上面就是将本地项目更新值指定分支的最新状态。关于我们的项目路径，分支名我是准备到了一个配置文件中，这个配置文件因为是本地化的，而且只面向我自己，所以我可以随心所欲的操作它了。
- 项目UPDATE之后，我们就需要进行打包，这里也是我在开发脚本的过程中发现的问题，每个项目的打包方式不一样，前后端的话甚至打包命令也是不一样的。所以我们还得讲打包地址与打包命令放置在配置文件中。目前我仅是针对我自己实现的脚本，所以这里只是后台打包命令写在脚本里，这里带后面改用
Python的时候进行优化。 - 因为我们需要对打包之后结果进行检测，所以这里我们需要将打包日志输出到指定位置。
mvn clean install -DskipTests > ${currentHome}/mvninstall.log 2>&1 &
进度条制作
- 上面我也提到了，有的项目在打包的时候需要耗费很长时间，如果不进行相应的提示的话，很容易给人造成脚本出错奔溃的假象，针对我们上一步记录了脚本打包时长，我们这里可以制作一个大概了进度条。关于进度条制作点我。
while [ $i -le 100 ]
do
printf "[%-100s][%d%%][%c]\r" $str $(($i)) ${ch[$index]}
str+='#'
let i++
let index=i%4
#echo $i
mavenstatus=`sed -n '/[INFO] BUILD SUCCESS/p' ${currentHome}/mvninstall.log`
sleep $SLEEPTIME
#echo $mavenstatus
#echo $i
#echo ${#mavenstatus}
if [[ ${#mavenstatus} > 0 ]]
then
i=100;
str=####################################################################################################
printf "[%-100s][%d%%][%c]\r" $str $(($i)) ${ch[$index]}
break;
fi
failmavenstatus=`sed -n '/[INFO] BUILD FAILURE/p' ${currentHome}/mvninstall.log`
#echo ${failmavenstatus}
if [[ -n ${failmavenstatus} ]]
then
echo 打包失败
exit
fi
done
- 加了进度条之后我们自动化过程中就不会显得尴尬了。在打包过程中我们可以选择干其他事情，也可以选择静静地欣赏。
上传服务
- 出包之后我们就可以上传到服务器上了。我们都知道上传使用的是
ssh,但是ssh是需要我们手动输入用户名密码的，如果需要我们手动输入的话那就并不是我们的自动化了，这里需要牵扯一下sshpass这个命令。还不知道赶紧去学学撒。
sshpass -p $PASSWORD scp -o ConnectTimeout=20 $mainPath$projectName/${SUB_PATH}$JARFILE $USER_NAME@$IP:~/$SAVE_PATH/$projectName
startstatus=`sshpass -p $PASSWORD ssh -o StrictHostKeyChecking=no -p 22 $USER_NAME@$IP "cd ~/$SAVE_PATH/$projectName; sh restart.sh > /dev/null 2>&1 & "`
- 如果之后还需要执行其他命令，我们都可以通过
sshpass来自动化执行。避免我们手动输入关键信息了，而且这一切都是本地化操作，我们只需要在配置文件中准备好服务的信息即可，也不需要担心泄漏的问题。
服务检测
- 有了上面的
sshpass命令，检测服务就更没啥难度了，每个项目对应的端口我们同样配置在配置文件中，我们可以借助于进度条的帮助不断轮训端口是否正常。
while [ $i -le 25 ]
do
printf "[%-25s][%d%%][%c]\r" $str $(($i*4)) ${ch[$index]}
str+='#'
let i++
let index=i%4
pid=`sshpass -p $PASSWORD ssh $USER_NAME@$IP "lsof -i:$PORT" | awk -F "[ ]+" 'NR>1{print $2}'`
#pid=`sshpass -p $PASSWORD ssh $USER_NAME@$IP "ps -ef | grep $projectName | grep -v grep" | awk '{print $2}'`
if [[ -n $pid ]]
then
if [[ $i <25 ]]
then
i=25;
str=#########################
fi
fi
sleep 2
done
开发过程遇到坑
- 万事开头难，所以在开发之初我就做好了心理准备。比如一开始打包时间特别长造成的假死状态。下面大概总结了几个问题：
| 问题 | 解决办法 |
|---|---|
| 耗时太长，造成假死 | 加上进度条友情提示我还活着 |
| 上传服务需要手动输入账号密码 | 借助sshpass实现免输入 |
| 无法做到量化 | 将动态值写入配置文件 |
| 重点是SHELL我不熟 | 学习SHELL |
- 针对配置文件目前我分为两类。这样方便进行不同项目的扩展。当然如果你也想实现一套只需要改改对应配置文件即可。
总结
- 整个过程从想法初现到最终脚本落地一共耗时了两个月。这两个月包含了我去现学SHELL的过程。
- 过程中虽然很累，但是结果是很享受的。如果你也在创作某个想法，请你一定要坚持下去。关于自动化部署也算是1.0问世了。后面根据自己计划在改用python进行优化一版。