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

因为公司用的是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 项目

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