博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

jenkins+svn完整打包并上传到linux服务器上

Posted on 2019-01-04 18:40  YouxiYouxi  阅读(2637)  评论(0编辑  收藏  举报

因为公司用的是svn版本管理工具并且部署在了windows服务器上,所以测试环使用jenkins需要部署两套环境,

一套是在本地windows服务器,jenkins从svn下载代码完成打包并上传到linux跳板机上

一套是在linux环境上,把跳板机上的包上传到对应服务器上并备份以前版本,重启新jar包

今天先讲如何在windows环境上完成打包并上传到linux服务器上

步骤;

1、jenkins安装好,配置好jdk.maven 环境,本身就有的可以自定义路径的,没有的可以再jenkins自行安装,在jenkins系统设置的全局工具配置中,

1.配置好maven 配置中的settings路径,配置好maven设置,指定工作位置存放, settings.xml 设置 localRepository:(地址可以自定义,方便管理)   ,一

2.jdk路径

3.maven路径

 

2.系统设置-全局工具设置配置好ssh

 

3.下载SSH Publishers插件并安装,这个工具是用来把打包的项目上传到跳板机上
jenkins基础数据搞好了,现在开始按照步骤开始打包并上传
1.新建一个maven项目
2.源码管理选择Subversion,正确填写svn项目路径和用户名密码
svn更新参数解释
  • Use‘svn update’ as much as possible

    • 第一次发布的时候,会把工作目录下的所有文件清空,然后check-out一份完整的项目到工作目录下;

    • 以后更新的时候,不会判断已有文件是否在svn里存在。比如工作目录下的文件123在svn里不存在,那么更新的时候不会删除123。

    • 不会判断工作目录下的文件是否被改动,只会判断svn是否有新版本需要更新。比如工作目录下的文件zzz.txt内容为zzz,svn上的zzz.txt内容为空,如果svn上zzz.txt没有新版本,则在更新的时候不会更新zzz.txt,也就是说如果手动修改了工作目录下的文件,如果此文件在svn上没有出现新版本,就不会更新。一旦svn上的zzz.txt有新版本后就会更新工作目录的zzz.txt,这时工作目录下会生成如下几个文件:zzz.txt、zzz.txt.mine、zzz.txt.r223、zzz.txt.r224,其中zzz.txt.r223为svn上老版本、zzz.txt.r224为svn上新版本、zzz.txt.mine为工作目录上的zzz.txt的副本、zzz.txt记录了文件变化。

    • svn上删除了文件,更新的时候,工作目录里的此文件也会被删除。但是如上例中的zzz.txt手动修改过,已经和svn上的不一样了,这时将不会被删除。

  • Alwayscheck out a fresh copy

    • 第一次发布的时候,会把工作目录下的所有文件清空,然后check-out一份完整的项目到工作目录下;

    • 每一次更新的时候,都会先清除工作目录下的所有文件,然后重新check-out一份完整的项目到工作目录下。

  • Emulateclean checkout by first deleting unversioned/ignored files,then ‘svn update’

    • 第一次发布的时候,会把工作目录下的所有文件清空,然后check-out一份完整的项目到工作目录下;

    • 以后更新的时候会判断工作目录下的文件是否在svn里存在,如果不存在则删除,如果存在且有新版本则更新。

    • 会判断工作目录下的文件是否被改动,不管有没有新版本,都会还原为svn上的最新版本。

    • svn上删除了文件,更新的时候,工作目录里的此文件也会被删除。

  • Use‘svn update’ as much as possible,with ‘svn revert’ before update

    • 第一次发布的时候,会把工作目录下的所有文件清空,然后check-out一份完整的项目到工作目录下;

    • 以后更新的时候不会判断工作目录下的文件是否在svn里存在。

    • 会判断工作目录下的文件是否被改动,不管有没有新版本,都会还原为svn上的最新版本。

    • svn上删除了文件,更新的时候,工作目录里的此文件也会被删除。

 

 

 

 

3.构建触发器选择构建什么样的触发,可以选择手动,轮询,定时构建

参数解释

build whenever a snapshot dependency is built

当job依赖的快照版本被build时,执行本job。

build after other projects are built

当本job依赖的job被build时,执行本job

build periodically

隔一段时间build一次,不管版本库代码是否发生变化。

poll scm

隔一段时间比较一次源代码如果发生变更,那么就build。否则,不进行build。

Poll SCM:定时检查源码变更,如果有更新就checkout最新code下来,然后执行构建动作。

 如果没有更新就不会执行构建

 

Build periodically:周期进行项目构建(源码是否发生变化没有关系)

 

每15分钟构建一次:H/15 * * * *   或*/5 * * * *

 

每天8点构建一次:0 8 * * *

每天8点~17点,两小时构建一次:0 8-17/2 * * *

周一到周五,8点~17点,两小时构建一次:0 8-17/2 * * 1-5

每月1号、15号各构建一次,除12月:H H 1,15 1-11 *

*/5 * * * * (每5分钟检查一次源码变化)

0 2 * * * (每天2:00 必须build一次源码)

4.构建环境

参数解释

Delete workspace before build starts:默认删除所有的,也可以设置删除特定的文件
- Patterns for files to be deleted:正则匹配删除哪些文件
- Apply pattern also on directories:规则是否也应用到文件夹
- Check parameter:是否删除,是个bool值,true则删除,false不删除.为毛感觉这个有点鸡肋
- External Deletion Command:执行外部删除命令
Abort the build if it’s stuck:构建阻塞的时候,根据超时策略处理.
- Time-out strategy:超时策略,有绝对时间,相对时间,根据以前的构建时间判断等
- Time-out variable:超时时间
- Time-out actions:超时后的处理,如终结,faile调或者写描述
- Add timestamps to the Console Output:在输出界面添加时间戳
- Use secret text(s) or file:使用密文,用于全局性的管理密码等,勾选后会在下方出现Binding,输入需要的用户名,密码证书等就可以了


5.Pre Steps  bulid执行之前的操作,可以再这里设置参数,没什么特殊需要的话,一般不需要填写,使用默认设置就即可

6.bulid 项目

 

有点事,后面再继续写,。。。。