一、jenkins实现持续集成部署发布
如果不采用工具的话，网站的发布更新是一个简单但麻烦的事情，在这个方面，jenkins是一个很好用的工具。Jenkins是基于Java开发的一种持续集成工具，用于监控持续重复的工作，包括持续的软件版本发布/测试项目。并可监控外部调用执行的工作。今天在本博客平台上部署好了jenkins并实现了一键更新发布。
1. 部署发布的过程
控制台输出：
Started by user Kermit
Building in workspace /dir/dir/jenkins/workspace/007CN
Updating http://svnkermit.cn/kermitsvn at revision '2016-08-02T13:51:41.677 +0800'
U keframe/coreapp/KeDebug.class.php
At revision 185
[007CN] $ /bin/sh -xe /tmp/hudson4815050691085860331.sh
+ fab -f deploy/fabfile.py production deploy
[117.217.87.217] Executing task 'deploy'
[localhost] local: tar -czf /tmp/tmpwb0BWN/04007CN.tar.gz -C /var/lib/jenkins/workspace 007CN --exclude .svn --exclude deploy --exclude uploads --exclude storage
[117.217.87.217] put: /tmp/tmpwb0BWN/007CN.tar.gz -> /opt/fabric_store/007/007CN.tar.gz
[117.217.87.217] sudo: tar -xzf 007CN.tar.gz; mv 04007CN tmp
[117.217.87.217] sudo: rm -f 007CN.tar.gz
[localhost] local: rm -rf /tmp/tmpwb0BWN
[117.217.87.217] sudo: cd /dir/fabric_store/007; mv tmp 20160802-1351
[117.217.87.217] sudo: cd /dir/fabric_store/007/20160802-1351/;cp -rf ./* /dirhome/dir/007.cn/;
[117.217.87.217] sudo: cd /dir/fabric_store/007;./delmore.sh;
Done.
Disconnecting from 117.217.87.217... done.
Finished: SUCCESS
之前本框架里的日志和缓存目录都放在application/目录下的cache和logs中，考虑到这些集成时不用更新，修改了框架将日志和缓存目录移动到ROOT下的storage目录里，这个是laravel框架里采用的目录架构，这样设计还是有其合理性，至少当我想使用jenkins持续集成时，我发现这很有必要。
2. Jenkins 发布的运行过程。
jenkins的集成过程也很简单。
1，从SVN地址中导出目录 2，将网站代码打包（此处去除要排除的目录及文件，比如刚才的storage缓存日志目录，以及由WEB自身更新的uploads目录等 3，将打包文件上传至目标服务器（可同时更新多个）。 4，在目标服务器上解压，并将解压后的文件夹覆盖到WEB目录中。 5，上面我增加执行了一个delmore.sh的shell脚本，功能是检查服务器上已有多少个目录（这些是每次集成解压后的目录，相当于一个历史版本的存放，可用于代码回滚），并控制最多保存3个回滚版本。
当然多服务器不建议执行shell脚本的，因为如果要使用shell脚本，就需要在每个服务器上部署好shell脚本，实际可将shell放至fabfile.py中执行。
二、Jenkins应用中的常见问题及解决办法列表
1. jenkins忘记密码了怎么办 - jenkins找回密码
一段时间没登录jenkins，可能把密码忘记了，再登录时总是提示：登录信息无效。请重试。If you are a system administrator and suspect this to be a configuration problem, see the server console output for more details.应该是密码或者账号不对了。怎么找回密码呢，只能去配置文件中修改了
首先找到jenkins的目录：-DJENKINS_HOME=/var/lib/jenkins
此目录下会有一个users文件夹，存放着各登录用户的账号信息，一个用户账户一个文件夹。文件夹里有配置文件：config.xml，内容如下：
如上面的配置文件，把passwordHash改成上面的值（对应密码是123456）,账户就是这个文件夹的名称，改好后登录jenkins，在管理平台上修改密码即可。
2. jenkins 报错Password input may be echoed.的解决办法
使用jenkins做自动部署时会报错：/usr/local/python27/lib/python2.7/getpass.py:83: GetPassWarning: Can not control echo on the terminal. Password input may be echoed.之前我其它的某篇博客里也曾有写过报这个错的解决办法：当时是在脚本中对密码设置进行了修改，把以下密码设置：
env.passwords = {'123.1.101.23':'123456'}
改成下面的这种方式就解决了这个问题。写法如下：
env.passwords = {'root@123.1.101.23':'123456'}
我的阿里云上装的jenkins是2.9-1.1 版本，这个报错实际就是在执行的时候在命令行中弹出了输入密码的提示，今天在公司服务器的服务器部署时也碰到了这个问题，凭着一点印象在我的博客里搜索这个报错，找到了我以前的解决办法，然而在公司的服务器上使用时却起不到效果，可能是版本差异的问题，公司里的jenkins版本是Jenkins ver. 2.19。最后使用的方法是密码的另一种写法。
比如有多个服务器需要部署，密码采用一样的密码，使用下面这种写法：
env.hosts = ['123.11.22.11','123.11.22.12','123.11.22.13']
env.password = 'abcdefg'
将密码的格式写成字符串，而不要写成一个服务器对应一个密码的格式。解决了这个问题，不过也不清楚具体导致问题的地方。做个笔记记录这个问题。
3. JENKINS报错hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
最近在给一些老项目添加jenkins发布权限，碰到的一些小问题做个记录。报错FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState ，详细如下：
FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:756)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:891)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at hudson.model.AbstractBuildAbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)atjenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)athudson.model.AbstractBuildAbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)atjenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)athudson.model.AbstractBuildAbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1727)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
An attempt to send an e-mail to empty list of recipients, ignored.
Finished: FAILURE
解决：这个报警比较陌生，看到后到网上查了查，有说自己是Jenkins构建工程名称用了中文导致的，因为我的项目发布归类是用的中文，但JOB是中文，开始也怀疑是中文的问题，改成英文发现并不是中文的问题，后来发现是发布目标服务器的权限问题（未给发布脚本使用的账号权限导致的这个错误）。再加到JENKINS,其顶部的JOB归类使用中文是可以的。
4. jenkins异常：We trust you have received the usual lecture from the local System..
[192.221.162.70] out: We trust you have received the usual lecture from the local System
[192.221.162.70] out: Administrator. It usually boils down to these three things:
[192.221.162.70] out:
[192.221.162.70] out: #1) Respect the privacy of others.
[192.221.162.70] out: #2) Think before you type.
[192.221.162.70] out: #3) With great power comes great responsibility.
[192.221.162.70] out:
#在停止发布之后显示的提示内容
[192.221.162.70] out: [sudo] password for jenkins: Build was aborted
Aborted by 04007.cn
Finished: ABORTED
解决：这次发布执行很久，开始还以为是网络慢，后来发现执行的时间太长有问题，中止执行后看到上面的报错password for jenkins: Build was aborted，这时才注意到上面的提示：We trust you have received the usual lecture from the local System 云云这句有点印象的话，有时在服务器上切换执行sudo时会显示上面的内容然后提示输入root用户的密码，说明当前脚本正在等着客户端输入密码，而在jenkins中无法操作所以卡住了。解决办法就是要么不加sudo执行看看。要么修改/etc/sudoers进行修改，给发布账号添加sudo权限。
文章来源
您阅读本篇文章共花了：
发表评论