Jenkins自动化部署-----持续交付

前言:

感谢之前带领过我的leader,让我能够知道什么是好的开发方法。

在很早之前就接触过敏捷开发。什么是敏捷开发,简单来说就是让软件可靠地,快速地发布出来的一种开发方法和技巧。

而敏捷开发中有许多的实践,可能并不是每一种实践都适合于你的团队,但是总有一种能帮助你们的团队快速地将软件可靠地,高可用地发布出来。

如果在读这篇文章之前,还没有接触过敏捷开发,那么推荐一门敏捷开发入门的书籍:《硝烟中的scrum和xp》,这本书是一本敏捷开发的入门入籍,介绍了诸如:产品如何编写backlog、怎么准备sprint计划、如何做回顾、如何做测试、如何管理scrum团队等基础的一些敏捷知识。这本书帮助了很多人了解了敏捷开发,是一本很经典的敏捷入门引导书。


至于关于持续交付的入门入籍,附上链接,欢迎下载持续交付-发布可靠软件的系统方法


chapter 1: 为什么要使用持续交付

在我们的开发部署工作中,有一些典型的反人类发布软件模式:

1.手工部署软件

无论是自己编写的系统,还是系统所需的一些软件:mysql、redis、git等,统统都是用手动部署的方式,每次需要发布、更新,都要连接到服务器上,手动地部署其新版本(例如:先将本地的war包上传到服务器的tomcat中,然后服务器上kill -9 xxx,重新启动tomcat这样),23333。。且不说这样部署的人力成本很大,不知道部署的软件是否有bug。并且还有一定的出错机率,在互联网竞争如此激烈的今天,这样的部署,肯定是不行的。

试想,如果有一种方法,当你本地Push代码之后,只需要在网页上点击一个按钮,或者点击按钮这一步都省略掉,再倒上一杯咖啡,你的系统已经部署到线上环境了,这样的自动化,不是更人性化吗


2.开发完成后才向类生产环境部署

很多团队表示,我们一定要把系统全部coding完成,才向(类)生产环境部署系统,这样有一个好处,就是大家更加专注于coding。不被打扰。但是也有一个坏处,就是无法及时反馈出系统中的问题,你的boss也无法知道系统究竟开发到什么程度,boss也无法向客户/他的boss展示项目的进程。

及时反馈在软件开发中是非常重要的,反馈得及时,能帮助软件能快速发现并解决掉软件中很多典型的问题:

(1)开发出的功能和boss想要的功能不一样

(2)软件开发中没被发现的bug

(3)页面实现和UI设计不一致等等。。。

那么有的人就会说,每部署一次都非常麻烦,需要打包、上传、部署配置、部署系统,而且容易出错。一旦部署失败,还要去看日志,找到bug并且修复后,重复以上的全部操作。

今天我们要讲解的jenkins就是解决这个问题的,只需要点击一个按钮就可以部署git上的代码,是不是特别方便。

3.生产环境纯手工配置管理

将配置文件、变量都通过手工的方式去部署是非常不科学的,这不仅需要一个部署专家,若是哪天这个专家请假或者离职,那么你们的团队便无法部署了。而且手工部署还极其容易出错,多台服务器,需要多次重复部署。

自动化是必然的趋势,那么典型的解决方案就是使用某个配置管理软件,或者将配置放在某个具体的脚本中,这样会使软件发布轻松很多


chapter 2: jenkins介绍

jenkins是一个开源软件项目,基于java开发的一款持续集成(Continuous Integration)工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

一切的目的都是快速反馈。

喏,下面就是这货的图标


猥琐中带着一丝优雅,23333。

jenkins的标语:

Build great things at any scale

  “以任何规模建造伟大的事情

 Jenkins,之前叫做Hudson,所以如果你在jenkins的很多地方,看到hudson这个单词,一定要知道他是jenkins的旧名字。

 Jenkins是基于Java开发的一种持续集成工具,用于监控秩序重复的工作,包括:

        1)、持续的软件版本发布/测试项目。

        2)、监控外部调用执行的工作。

        下面是一个官网的简单图形介绍:

        

chapter 3: jenkins安装和配置

上面介绍了那么多,估计你也没看,我们关心的只有软件的使用方法(23333)。那么我们下面就进入jenkins的安装和配置

环境准备:

首先,你的机器上面,需要安装jdk、git、maven相关的运行环境,我这里使用的jdk1.8、maven3.3.9、git2.16.2

jenkins安装:

下载地址https://jenkins.io/download/,仅下载war包。这个下载就不需要截图了吧。

得到war包后,有两种运行jenkins的方式

1.将war包放在tomcat的webapps目录下,启动tomcat

2.命令启动 java -jar 下载的war包名.war --httpPort=9004

第二种方式启动后,会在/home/xxxxx/.jenkins文件夹下构建jenkins的目录。

你想知道第一种在哪构建这个目录?我也不知道,自己试试咯,启动后日志中有显示位置



用浏览器访问http://localhost:9004 (tomcat启动,访问http://lcoalhost:9004/jenkins),得到以下页面


然后输入密码就可以了。。

密码,你不知道什么密码?图片中红色的部分不是已经说了密码在哪里了吗。打开文件,copy,paste就行了。

接下来就到了插件配置页面,建议翻墙进行安装所需要的插件,或者现在直接选择skip plugin installations跳过



设置成功之后,就跳转到用户名密码配置页面,这个用户名和密码用于以后的jenkins登录


这是你之后用来登录的用户名密码,最好记住哦~


当当当当~~到这里,你的Jenkins已经配置成功了,成功进入jenkins的主页了!恭喜恭喜



那么接下来,我们就要开始搭建自动化部署的pipeline了。

什么,你说什么是Pipeline?好吧,简单讲解一下


喏,就是上面这货,三个模块,第一个模块是构建模块,用来执行单元测试+build项目形成二进制文件,由于我使用的是Springboot,所以得到的是一个jar包。第二个模块是部署模块,当第一个模块构建成功(变绿),才会触发第二个模块,如果第一个模块单元测试或者运行失败,当前模块就会变红,那么就不会运行第二个模块,当然,这个触发是自己配置的。第三个模块,就是线上环境了,第二个模块运行成功后,就开始运行第三个模块。

当你push了代码之后,只需要点击上面的Run那个按钮,你的系统就已经部署到线上了,是不是很神奇。


你想要搭建这个玩意,首先,你需要给Jenkins安装几个插件,点击这里安装插件



进去了之后,根据下图进行安装插件哦


你需要安装的插件有:

Build pipeline Plugin:没有这个,就没有PipeLine视图

Build Time Out:构建超时插件

Deploy to Container Plugin:部署容器插件

Email Extension Plugin:发送邮件插件

Git

JDK Tool Plugin

PipeLine

Publish over ssh

Timestamper

Workspace Cleanup Plugin

安装好以上插件后,进入上图的installed,勾选上以上的这些插件,使其开启使用。


配置好上述插件,接下来我们就要来配置JDK,Maven,git环境了

注意:这些环境必须配置。

(这里有一个小小的插曲,当初我并没有配置这些环境,以为Jenkins默认带有的这些插件环境可以生效,傻傻地运行等待了两个小时。然而事实证明,并没有什么卵用,必须要配置这些东西。)

在上上张图中,点击


进行配置


你需要配置以下的东东,首先是JDK


将JDK配置到相应的bin目录上级,也就是你的$JAVA_HOME位置


然后配置Git



注意:这个git有点日怪,他不是配置到bin目录上级,需要配置到具体的可执行文件位置!看上图中的文字Path to git executable。如果换成Java的话,就应该配置$JAVA_HOME/bin/javac 这个级别的,可执行文件~



最后配置Maven



这里也是配置MAVEN_HOME哦。到bin目录上级就可以了

在配置maven的setting.xml时,建议加上阿里的mirror,这样运行时,下载依赖的速度可以快几倍

在setting.xml中的<mirrors>标签中添加以下代码即可

<mirror>  
    <id>nexus-aliyun</id>  
    <mirrorOf>central</mirrorOf>    
    <name>Nexus aliyun</name>  
    <url>http://maven.aliyun.com/nexus/content/groups/public</url>  
</mirror> 


上述的Maven、JDK、Git软件安装就不再赘述。自行百度。


一切配置成功后,最好重启下jenkins使上面的插件和环境生效,接下来开始构建Pipeline

回到首页,点击new Item 先创建个文件夹,方便以后多个项目分组方便


添加文件夹后,你的首页上就会多出一个文件夹


其中outer是我文件夹的名字,名字随意就好

点击outer进入文件夹

再点击左侧的New Item ,然后创建Maven项目



点击OK后进入配置页面、这里有几个地方需要配置

先配置你的源代码所在git位置,branch specifier可以选择你代码的分支


general中配置,显示几天的几个版本的以前的构建信息,方便查看错误日志


Build Triggers中。勾选Poll SCM中的Schedule,这里需要配置一个五位数的表达式

分别代表:分钟,小时,天,月,星期几

例如配置: 5 * * * *  代表每个小时的第五分钟构建

0 0 10 * * 代表每个月10号构建

这个表达式有点像Spring task中的schedule表达式,不清楚的可以去百度了解一下



配置maven的位置以及运行maven的命令,有机智的小伙伴就发现,为什么要使用Maven的package命令,而不是直接spring-boot:run运行呢。呵呵,我试过,运行后会直接阻塞,PipeLine压根看不到结果是否成功,也没法结束。所以只能先打包再运行,运行脚本在第二个模块中


勾选这玩意儿,用于删除以前的项目



最后重点来了,就是下面这货。这个等下再讲,先配置上就行了。



第一步的Maven Project已经构建成功。接下来回到outer文件夹中,选择New Item ,创建一个freestyle project 


build中填写:

BUILD_ID=dontKillMe nohup java -jar /Users/xiangnan/.jenkins/workspace/outer/test_project/target/BootRedis-0.0.1-SNAPSHOT.jar &

BUILD_ID=dontKillMe nohup + & 的意思是让其springboot运行成功后,到后台去运行,不阻塞当前的pipeline。


当然,这里的脚本只是一个最简单的命令运行脚本,你也可以将脚本放在git中,或者放在服务器上,每次构建就拉取新的脚本并且运行。这是一种思路,脚本的使用可以非常灵活,不一定需要直接运行jar包。

到这里,我们的两个项目就已经构建成功了。但是到现在还没有PipeLine的展示

回到outer文件夹中,点击+按钮,选择build Pipeline View,并输入pipeline的名字




接下来进入pipeline的配置页面,在这个页面中,在pipeline flow的upstream项,选择之前的maven项目,我的是test_project


最后点击OK。大功告成,你将看到如下页面


这就是我们前文中提到的Build PipeLine。点击Run即可从git上拉代码并运行项目到当前机器中了哦。

先运行第一个test_project,当第一个模块运行单元测试、打包成功后,才会触发运行第二个模块--即部署springboot.jar

那么是怎么触发的呢

我们回到之前没有讲解的一张图


在途中我们配置了几个地方,

Projects to build:当项目构建完成,生成war包后,出发哪个项目

Trigger when build is : stable  -- 只有当前项目构建成功后,才开始构建下一个freestyle project

除了stable还有其他的几个选项,


根据需要进行选择需要什么条件去触发下一个模块。例如:Failed,当失败时构建下一个项目

Predefined parameters: 预定义变量,必配

只有配置了预定义变量,才能根据${BUILD_NUMBER} -- 构建号,${GIT_COMMIT}--git提交的版本号,根据这两个变量去触发下一个模块,没有这个配置,就无法触发下一个模块.


总结:


以上。整个Pipeline就部署完成了。但是其实这只是部署的一个入门,提供了一个思路,Jenkins还有很多其他的功能,例如构建失败时发送邮件,自定义脚本,git代码Push完成后立即触发Run等等,Jenkins非常的灵活,功能也非常多,等待你自己去探索。

感谢阅读此文章。

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭