Jenkins实战应用–Jenkins构建中tag的应用

转自：http://www.eryajf.net/1676.html

 

系列汇总*

这是一个系列文章，大大小小到今天惊然发现竟然已经累计二十篇了，也就不得不做一个小汇总。回想当初写第一篇文章的时候，就已经决心事无巨细，一应认真的走下来，回头遮望，看着皇皇这么多文章，一股强烈的成就感就此油然而生，于是便有了这些汇总整理。在这个过程当中，好像也帮助过不少的人，这是让我尤其开心的事情，同时也结识了一些志同道合的朋友，再没有比这更让人觉得愉悦的事情啦！也希望以后写出更多类似的系列文章。

文章汇总地址如右：Jenkins入门教程。

如果相中哪个，点击进去便是。希望正在读这段话的你能够在这个小系列中获得自信以及喜悦！

1，缘起。

许多公司在做安卓的构建或者其他项目构建的同时，会有打tag到Gitlab的需求，这个需求的存在有其实在的价值意义，不仅仅让每一次我们发布过的代码有记录存留，也能够方便一些其他的功能（比如回滚），因此，今天就来说说这个事儿。

这个功能的实现依赖于Jenkins的git插件，不过一般都默认有安装。

先准备一个测试项目，内容如下：

然后来到Jenkins处，做一些简单的功能，能够用于测试验证即可。

执行shell处加一些简单的操作：

  1. git pull origin master
  2. echo "**********************************************"
  3. cat README.md
  4. echo "**********************************************"

进入正式配置之前需要先安装本文的主角Git Parameter插件，插件详情，可以点我查看。

在构建后的操作中添加Git Publisher，然后如图中所示配置：

在构建后操作当中选择Git Publisher，然后如图配置：

  • 配置一：定义tag名称，release-$BUILD_NUMBER这里取用了一个Jenkins的环境变量，用于每次的tag自增问题。
  • 配置二：选中，以表示创建一个新的tag。
  • 配置三：要推送的项目。

接着我们构建一下看看效果：

看样子tag已经打好并且推送到远程服务器去了。

现在去git里边看看是否有了。

图中圈起来的地方可以看到，正好与我们构建此时对应的，创建了三个标签。

现在我们模拟开发，更改一下项目文件内容，然后再构建一下看看情况。

来波操作：

  1. Administrator@liqilong MINGW64 ~/Desktop/gittest/eryajf (master)
  2. $ echo "第二次添加内容用于测试" >> README.md
  3.  
  4. Administrator@liqilong MINGW64 ~/Desktop/gittest/eryajf (master)
  5. $ git commit -a -m "add two"
  6. warning: LF will be replaced by CRLF in README.md.
  7. The file will have its original line endings in your working directory.
  8. [master 822b2f3] add two
  9. 1 file changed, 1 insertion(+), 1 deletion(-)
  10.  
  11. Administrator@liqilong MINGW64 ~/Desktop/gittest/eryajf (master)
  12. $ git push
  13. Enumerating objects: 5, done.
  14. Counting objects: 100% (5/5), done.
  15. Delta compression using up to 4 threads.
  16. Compressing objects: 100% (2/2), done.
  17. Writing objects: 100% (3/3), 307 bytes | 76.00 KiB/s, done.
  18. Total 3 (delta 0), reused 0 (delta 0)
  19. To 192.168.106.70:linux/eryajf.git
  20. 635b61c..822b2f3 master -> master

然后再去构建一下：

第四次构建，已经看到刚刚模拟开发所添加的内容了。

那么现在，就可以引出这个自动打tag的功能所带来的另外一个大方便了，那就是方便回滚。

2，回滚功能。

我们可以在参数化构建当中进行参数的定义，依赖于Git版本控制的特性，当用户选择的是构建时，可以选择对应的分支进行构建，当用户选择的是回滚是，那么可以选择对应的tag进行回滚。事实上与分支的构建回滚是一个道理，不过这里直接选择tag，也非常方便。

那么在验证之前，我们需要对Jenkins进行一些小小的调整，通过添加刚刚表述的参数，以及执行的shell的配合，来完成这样一个构建回滚各有分工的一个事情。

1，添加mode选项。

在参数化构建过程中先添加一个选项参数，从而让构建以及回滚两种情况存在。具体配置如图:

2，再添加branch选项。

然后添加一个用于构建不同代码分支的字符参数，这个是一个很常规的配置，就不做过多介绍，具体如图：

3，添加Git Parameter选项。

然后添加一个用于回滚不同tag的选项，这里的tag是我们项目自动生成的，随后会做一下总结，具体如图：

4，修改shell内容。

修改一下shell的执行内容，做一个简单判断，脚本如下：

  1. cd $WORKSPACE
  2. if [ $mode == "deploy" ];then
  3. git checkout $branch
  4. git pull
  5. echo "**********************************************"
  6. cat README.md
  7. echo "**********************************************"
  8. else
  9. git reset --hard $tagbak
  10. echo "**********************************************"
  11. cat README.md
  12. echo "**********************************************"
  13. fi

如果你对Jenkins熟悉的话，那么看到这个地方，估计就已经能够知道，上边的功能是什么了。

我们的开发进行日常开发，然后进行日常构建，一切就走分支这一条了，没tag这边啥事儿，只不过在每次构建的时候，都创建一个与构建历史数一致的tag，为了不让这个tag浪费，那么我们就废物利用，通过这个自动生成的tag，实现了回滚的功能。

开发同学专注开发（branch），运维同学专注部署（deploy），一旦需要回滚（rollback），利用程序自动生成的tag（tag）来进行回滚咯。这，就是各有分工。

ok，最后是验证的时刻了。

3，验证。

验证也非常简单，通过三次构建即可验证：

  • 构建一：初始内容，正常构建。
  • 构建二：添加内容，正常构建。
  • 构建三；直接回滚，验证结果。

1，构建一。

为了更清晰的看实验效果，我将刚刚的历史清空，重打鼓另开张，新建一个项目进行测试。

现在准备出测试文件，内容如下：

进行常规构建：

2，构建二。

模拟开发，添加内容：

进行常规构建：

3，构建三。

直接通过tag进行回滚。

然后查看构建结果：

注意我圈住的地方，基本上就是按我们所想的所走的，而结果，也正是我们所想要的。

本篇文章需要一定的基础，从而才能够顺畅阅读以及实践，除此之外，更需要大量的耐心，诚心，进行钻研学习，从而才能够真正在此，有所收获。

posted @ 2019-11-24 16:12  heycomputer  阅读(356)  评论(0)  编辑  收藏  举报