开发一时爽,集成测试、集成部署什么的最麻烦了,有没有,尤其是项目开发完成,QA 测试阶段,每天上 N 个版本。
累不累?真累啊。
烦不烦?真烦啊。
怎么办,用 Jenkins 吧。
Jenkins 是非常流行的开源的持续集成工具。它提供了众多的插件,可以使项目构建、部署、发布自动化实现,并且部署简单,使用方便。
Jenkins 有众多插件支持,并且可以灵活的和自定义脚本做集成,无论是前端项目还是后端项目,无论是哪种语言实现,只要是可以部署到服务器上的,都可以用 Jenkins 来简化我们的工作,节省时间,提高效率。
这里简单记录了一下 Jenkins 的安装配置,以及通过 Jenkins 快速简单的构建发布 Maven Java 项目。还没有使用的开发朋友们,赶快用起来吧。
1、到官网 https://jenkins.io/download/ 下载 war 包,war包自带Jetty服务器 ,只需运行命令:
java -jar jenkins.war --httpPort=10000
就可以在 10000 端口启动 jenkins 。
2、第一次启动的时候,会生成一个随机密码,如下:
3、在浏览器访问 10000 端口,出现如下界面,输入 Administrator password 密码,即上面的随机密码
4、"Continue" 之后,开始初始化,稍等片刻,出现如下界面,默认选择 “Install Suggested Plugins”即可。
5、开始默认插件的安装,需要等待一段时间。安装完成后,输入用户名和密码等信息即可完成初始配置。
6、进入“全局工具配置”页面,配置好 JDK、Git、Maven、Maven Configuration 。建议全部手工安装,然后手动配置。
7、进入插件管理,搜索 Maven Integration plugin ,并安装,主要是为了构建 maven 项目。
进入首页,点击新建,并选择"构建一个 Maven 项目"。
点击确定之后,进入项目配置页面,接下来对项目做完整配置,制定个性化的集成方案。
填写项目名称、描述等信息
以 Git 为例,可以是 GitHub 、GitLab 等代码托管系统。
1、勾选 Git,先以 https 协议为例,填写 Repository URL ,即仓库地址,例如:https://github.com/username/jenkins-test.git
2、添加一个证书,这里是 https 协议,增加一个账号密码类型的证书
3、 然后选择一个分支,默认是 master 分支。
项目除了可以手动构建之外,还可以设置触发器,jenkins 提供了几种比较有用的触发器
当 pom.xml 中的<dependency>
发生了变化时,就会触发一次构建,也就是修改了maven 依赖包,比如引入了新的包、删除了之前的包、更改了包版本等。
如果选择使用远程构建触发,在身份验证令牌这里设置好一个 token 值,可以自己随意定,之后访问 JENKINS_URL
/job/maven-svn/build?token=TOKEN_NAME
或者 /buildWithParameters?token=TOKEN_NAME
,例如我这里就可以访问 http://127.0.0.1:10000/job/maven-svn/build?token=my-jenkins-token
当一个其他项目构建之后触发构建当前项目,可以选择是其他项目构建成功、不稳定或者失败之后触发。
设置一个 Cron 表达式,例如每天固定时间、每隔几个小时、每周几等等,不管源代码是否发生了变化,都执行构建任务。如图,是每天凌晨 3 点执行。具体 Cron 参看说明即可。
GitHub 专用的触发器设置,需要配合 github Webhooks 使用。
区别于 Build periodically ,同样是设置一个 Cron 表达式,不同的是,会检查源代码是否发生了变化,如果有变化才执行构建,否则不执行。
一般不需要更改。
构建之前的动作,比如构建前执行一段 shell
脚本。一般不用。
正式构建,因为这里是创建的 maven 项目,所以主要就是配置 Root POM 和 maven 命令。
如图,意思是主 pom 文件名称为 pom.xml ,需要执行的 maven 命令是 clean package ,即先清理,再打包。
点击“高级”可以设置更多的 maven 配置,具体没有用过。
系统自带的邮件配置
1、进入「系统管理」- 「系统设置」。
2、找到 Jenkins Location ,配置上 Jenkins URL 和 系统管理员邮件地址(即发送通知邮件的邮箱账号)
3、然后找到 邮件通知并点击高级配置,填上 SMTP 服务器、勾选使用 SMTP 认证、用户名(此用户名须和上面系统管理员邮件地址一致)和密码、勾选使用 SSL 协议。
4、勾选“通过发送测试邮件测试配置”,填写需要发送测试的邮箱,可以测试一下配置是否成功。
5、回到项目配置页面,勾选 “E-mail Notification”,填写通知人列表(多个邮箱用空格分隔)。
到此配置完成,但是只能在构建失败时发送邮件通知,功能过于简单。下面介绍扩展插件的方式。
Email Extension Plugin 配置
1、到「系统管理」-「管理插件」下安装 Email Extension Plugin 插件。
2、进入 「系统管理」- 「系统设置」,找到 “Extended E-mail Notification”并打开高级设置,设置好 SMTP server、勾选 Use SMTP Authentication、填写邮件发送方账号和密码、勾选 Use SSL。这些信息是必须的。另外,可以填写默认通知列表、默认内容类型格式、默认邮件主题、默认邮件内容等配置。
3、回到项目配置,找到“构建后操作”,点击“增加构建后操作步骤”,选择 “Editable Email Notification”,填写邮件通知列表(逗号分隔)、Content Type、Default Subject、Default Content等内容
4、添加触发器,可以在构建前、构建成功、构建失败等多种状态下发送邮件通知。这里配置了失败和成功两种状态触发器,并且每个触发器都可独立配置通知人、邮件主题、内容等,如果配置了会覆盖上一步的默认配置。这里要注意的是,通知人默认是 Developers ,需要改成 Recipient List。
5、保存配置,并构建项目,可以受到如下格式的邮件通知
集成钉钉群通知
1、首先在钉钉客户端新建一个通知群,点击聊天机器人。
2、选择一个自定义机器人。
3、点击添加,会自动生成 webhook 地址。
4、到「系统管理」-「管理插件」下安装 Dingding[钉钉] Plugin 插件。
5、回到项目配置页面,增加构建后操作步骤,选择“钉钉通知器配置”,填写钉钉access token,即上一步 webhook 地址中的 access_token 参数值,并选择通知时机。
6、最后构建项目,将会收到如下通知。
项目构建完成,对于整个集成部署来说,只是完成了百分之五十。剩下就是部署发布了,到了发布这一环节就需要对接其他功能或系统了。
构建完成之后执行的动作,可以选择只在构建成功后、构建成功或不稳定时、不管构建结果如何三种时机。
例如在构建成功后,可以执行一段 shell 脚本,由此,我们可以发挥想象,通过这一段 shell 脚本能做哪些操作:
1、比如通过脚本调用一个 API 接口,通过然后 API 主动下载构建好的包;
2、比如通过脚本主动推送打好的包到远程待部署服务器
之后,如果是简单的部署环境,例如之后两三台服务器,可以在待部署服务器上用脚本实现。
如果是机器比较多的情况,可以接入 saltstack 等运维工具。
如果是 docker 场景下,另有其他的实现方式。
下面结合 Publish Over SSH 和 shell 脚本完成远程部署 war 包到远程 tomcat
1、到“系统管理”--->“管理插件”,在可选插件中搜索 Publish Over SSH,完成安装。
2、到“系统管理”--->“系统设置”中,找到 Publish over SSH 设置区域,配置 ssh server 配置
Passphrase:如果是秘钥登录,在使用ssh-key 创建秘钥的过程中会提示输入密码,如果输入了,这里就填写那个密码
Path to key:秘钥文件(私钥)在 jenkins 服务器的位置
SSH Server Name:服务器名称,随意填写,帮助标示服务器
Hostname:需要连接 ssh 服务器 IP
Username:用户名
Remote Directory:远程目录,即发送的文件会保存到这个目录,这里就是 war 包要临时保存的位置
Use password authentication, or use a different key:使用密码或其他的key
Passphrase / Password : 密码或其他秘钥文件创建时所用的密码,这里使用的是用户名密码方式。
3、配置好之后,点击 “Test Configuration” 按钮,如果提示 success 则表示配置成功,保存配置。
4、回到项目配置页面,在“增加构建后操作步骤”中选择 “Send build artifacts over SSH”
可以配置多个SSH Server,就是说可以把构建出来的包部署到台服务器上。
Name :选择刚刚配置的那个部署服务器
Transfers: 传输器,可以配置多个 Transfer Set,也就是说如果一台服务器上有多个 tomcat,可以通过不同的Transfer Set 传输,并且执行特定的命令。
Source files:源文件,即构建好的 war 包,这里是选择所有的 war 包。
Remove prefix : 要移除的路径前缀,如果 Source files 是 /target/xxx.war ,这里填写 /target 就可以在发送到部署服务器的时候,在 Remote directory 目录不创建 target 子目录,而直接将 xxx.war 发送到 Remote directory 根目录。注意:如果是多个 war 包,Remove prefix 必须是这几个 war 包所在路径共有的路径前缀(即以 Remove prefix 开始的目录)
Remote directory:部署服务器存放 war 包的目录,如果为空,则默认继承之前配置的路径
Exec command: 在部署服务器上执行的部署脚本,脚本要放在部署服务器上面。
5、根据具体的环境配置等信息,写一个shell 脚本文件,即上面的 deploy.sh 。脚本要完成的内容为:先查到要部署的那个tomcat 实例的 pid ,然后 kill 掉它,接着将之前的 war 包备份一下,然后将刚刚发送过去的 war 包复制到 tomcat 的 webapps 目录下,最后调用 bin 目录下的 ./startup.sh 脚本启动 tomcat 。
以上只是一个简单配置和部署过程,用与开发测试集成部署场景或者服务器很少的情况下。
也可以通过点击{阅读原文}到我的博客上查看。