jenkins基础安装与配置请看这里 传送门
jenkins持续集成的体系：
Linux + svn/git+ Jenkins + Maven + Jdk
1.持续集成的优点：
- 解放劳动力
- 避免人为失误
- 提高效率
- 质量持续反馈
- 质量保障
2. 配置job(没有Publish over SSH这个插件的，提前装一下)
|
1 |
打开Jenkins的“系统管理>管理插件”，选择“可选插件”，在输入框中输入“Publish over SSH”进行搜索，假设搜索不到能够在“已安装”里确认是否已经安装过。在搜索结果中选中“Publish over SSH”。点击页面的“直接安装”button。系统会自己主动安装。此插件安装后不须要重新启动Jenkins。假设插件成功安装在“系统管理>系统设置”会出现相关配置项。 |
3. Publish over SSH插件配置，远程 ssh 服务器(这个服务器，就是你要发布项目到他上头的机器，可以配置一台或者多台)
插件成功安装后使用前须要在“系统管理>系统设置”中进行配置。处如图：
|
1 2 3 4 5 6 7 8 9 10 11 |
每一项主机配置都能够被SSH Server的设置所覆盖，这种设计有一个优点。在server环境比較规范的情况下，能够省去每个SSH Server分别配置的繁琐步骤。 参数说明： Passphrase：SSH的password,使用username/password登录时为username的password。使用私钥登录时为私钥的password。 Path to key：SSH私钥的文件路径,私钥文件的路径，能够是绝对路径。也能够是相对$JENKINS_HOME的相对路径 Key：私钥导出后的文本内容 优先级： 假设“Key”和“Path to key”都设置，则“Key”的优先级较高，因为私钥的password是“Passphrase”中设置的内容。 Disable exec：禁止在目标机上运行命令。 勾选后将会忽略在Job配置中“Exec command”选项中设置的命令。Jenkins的说明文档中的“The Disable exec in the advanced settings for individual configurations will be ignored.”没有全然理解。从实际效果来看，仅仅要“Disable exec”被勾选后，无论SSH Server中是否勾选“Disable exec”。Job中设置的命令都将补忽略。 |
SSH Server()
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
SSH Server配置 为上面公共密码(Publish Over SSH)对应运行的主机配置，分“基本设置”和“高级设置”两部分。 “基本设置”主要是运程机IP、SSHusername、SSHport、连接超时时间等。 “高级设置”主要是一些连接超时设置，单个主机配置私钥设置, 以及端口转发和主机跳转设置(即从远程主机跳转到另一台机器去) 如在192.168.66.31这台机器上有userA和userB两个用户分别用来部署"应用A"和“应用B”。这样在SSH Server中部署2个各自用户,他们各自选择各自使用的用户发布项目即可，因为密码都使用的公用秘钥。 參数说明 Name SSH节点配置的名称。在Job(新建工作任务)中使用Publish over SSH插件时，此名称将出如今“SSH Server”中“Name”的下拉列表中 Hostname 通过SSH连接到的机器的主机名或IP Username SSH服务使用的username，使用key进行连接时为key指定的username Remote Derictory 运程机器上真实存在的文件夹，而且“Username”指定的用户要有访问此文件夹的权限。插件将把文件传送到此文件夹下。一般都写用户根下即可 |
注意：这里添加的主机，如果密码更新了的话，要删掉重新添加，否则就算你修改了 Passphrase 为最新密码，他还是会报连接不上，删掉下面的主机配置重新添加就可以了。
在job(工作任务)中配置 Publish over SSH
注意: 这里的 Exec command 如果是脚本，必须在你远程机器中有才可以执行,否则就会报找不到脚本文件。
|
1 2 3 4 5 6 7 8 9 10 11 |
參数说明 Name: “系统管理>系统设置”设置的SSH Sverver的名字列表。 Source files: 拷贝到运程机上的文件。相对workspace的路径(jenkins下你的工作项目下的源码目录)，也支持表达式，如“**/*.war”。 Remove prefix: 文件复制时要过滤的文件夹，如上图中的target文件夹。 Remote directory: 文件得到到远程机上的文件夹，此文件夹是相对于“SSH Server”中的“Remote directory”的。假设不存在将会自己主动创建。 Exec command: 在这里能够填写在运程机器上运行的脚本，如：应用部署脚本。也可以调用bash命令执行服务器中脚本 |
开始构建工作任务
在左边栏选择新建
填写任务名称，选择构建类型(这里我选自由构建)
构建环境 （同上面部分的讲解）
构建操作：
|
1 2 3 |
#依次执行clean、resources、compile、testResources、testCompile、test、jar(打包)、install等8个阶段,-Dmaven.test.skip=true，不执行测试用例，也不编译测试用例类。 mvn clean install -U -Dmaven.test.skip=true |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
maven 打包构建相关命令 1、命令 mvn clean package 依次执行clean、resources、compile、testResources、testCompile、test、jar(打包)等７个阶段。 mvn clean install 依次执行clean、resources、compile、testResources、testCompile、test、jar(打包)、install等8个阶段。 mvn clean deploy 依次执行clean、resources、compile、testResources、testCompile、test、jar(打包)、install、deploy等９个阶段。 2、区别 package 命令完成了项目编译、单元测试、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库 install 命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库 deploy 命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库 |
|
1 2 3 4 5 6 7 8 9 10 |
mvn clean package -Dmaven.test.skip=true mvn clean install -Dmaven.test.skip=true Maven命令解析： Maven中-DskipTests 和 -Dmaven.test.skip=true的区别 在使用mvn package进行编译、打包时，Maven会执行src/test/java中的JUnit测试用例，有时为了跳过测试，会使用参数-DskipTests 和 -Dmaven.test.skip=true，这两个参数的主要区别是： -DskipTests，不执行测试用例，但编译测试用例类生成相应的class文件至target/test-classes下。 -Dmaven.test.skip=true，不执行测试用例，也不编译测试用例类。 |
Exec command选项脚本解析：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#!/bin/bash Ctime=$(date +'%Y%m%d%H%M%S') #jar包名称 APP=factor-assets-admin-1.0.0.jar #jar包存放目录(这个目录自己实现创建好,或者你也可以使用脚本创建) AppInstallDir=/opt/factor-assets-admin-uat #旧版本jar包备份目录 AppBackupDir=/opt/backup_uat #Pid=`ps aux | grep "factor-admin" | grep -v grep | awk '{print $2}' ` ###创建上传目录及备份目录 mkdir -p /opt/backup_uat/upload_war /opt/backup_uat/backup_war ###杀掉旧进程 ps aux | grep "factor-assets-admin" |grep "spring.profiles.active=uat"| grep -v grep | awk '{print $2}' |xargs kill -9 ###备份旧jar包 tar -zcPf ${AppBackupDir}/backup_war/${APP}_${Ctime}.tgz ${AppInstallDir}/${APP} ###mv上传的新jar包 cp -r ${AppBackupDir}/upload_war/factor-assets-admin-1.0.0.jar ${AppInstallDir} ls -l ${AppInstallDir} ###启动新jar包 cd ${AppInstallDir} && /usr/bin/nohup /opt/jdk_1.8/bin/java -jar ${APP} --spring.profiles.active=uat & &> /dev/null ps aux | grep "factor-assets-admin" |grep "spring.profiles.active=uat" |grep -v grep echo "Start Success!!!" |
spring.profiles.active=uat 解释：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
我们在开发Spring Boot应用时，通常同一套程序会被应用和安装到几个不同的环境，比如：开发、测试、生产等。其中每个环境的数据库地址、服务器端口等等配置都会不同，如果在为不同环境打包时都要频繁修改配置文件的话，那必将是个非常繁琐且容易发生错误的事。 对于多环境的配置，各种项目构建工具或是框架的基本思路是一致的，通过配置多份不同环境的配置文件，再通过打包命令指定需要打包的内容之后进行区分打包，Spring Boot也不例外，或者说更加简单。 在Spring Boot中多环境配置文件名需要满足application-{profile}.properties的格式，其中{profile}对应你的环境标识，比如： application-dev.properties：开发环境 application-test.properties：测试环境 application-prod.properties：生产环境 针对各环境新建不同的配置文件application-dev.properties、application-test.properties、application-prod.properties 这三个文件均都设置不同的server.port属性，如：dev环境设置为8080，test环境设置为9090，prod环境设置为80 application.properties中设置spring.profiles.active=dev，就是说默认以dev环境设置 测试不同配置的加载： 执行java -jar xxx.jar，可以观察到服务端口被设置为8080，也就是默认的开发环境（dev） 执行java -jar xxx.jar --spring.profiles.active=test，可以观察到服务端口被设置为9090，也就是测试环境的配置（test） 执行java -jar xxx.jar --spring.profiles.active=prod，可以观察到服务端口被设置为80，也就是生产环境的配置（prod） 启动jar包 ：java -jar app.jar --spring.profiles.active=dev |
构建后操作(非必填)
保存->应用后点立即构建
构建成功
- 本文固定链接: https://www.yoyoask.com/?p=2905
- 转载请注明: shooter 于 SHOOTER 发表
这个作者貌似有点懒，什么都没有留下。