jenkins+python持续集成
搜索jenkins,进入官网,5分钟以内相信你能找到适合你操作系统的安装步骤。此处为省事,列出centos步骤(注意安装稳定版)
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins
如果你系统里没有Java,那么sudo yum install java
启停service jenkins start/stop/restart
或者systemctl start/stop/restart jenkins
不要问service start xxx和systemctl(centos7引入)啥关系,后者是用来替代前者的。具体问百度。启动后,验证安装是否成功,浏览器访问http://localhost:8080/,看到老爷爷(jenkins logo)就行。
要是遇到奇葩问题,看这里 https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Red+Hat+distributions
配置前安装必要插件:
Git Plugin:使用Git作为源代码管理
Python Plugin:Adds the ability to execute python scripts as build steps.
Violations:代码质量检测,支持pylint、jslint等
配置job
1.新建-->job-->自由风格
2.填写git 地址,触发器选择Poll SCM, Schedule可选
3.填写脚本:第二行#!/usr/bin/bash/...是给jenkins看的,让jenkins不要输出每条命令
#!/usr/bin/bash #!/usr/bin/bash/... source /home/luodaihong/py27/bin/activate cd /home/luodaihong/workspace/django-privilege/example coverage run --source=privilege manage.py test privilege coverage report -m --skip-covered pylint --output-format=parseable privilege > pylint.xml || exit 0
coverage pylint自己安装咯
4.增加构建后操作步骤-->Report Violations--> pylint后填写pylint.xml --->Faux Project Path填写实际工程路径,也就是脚本中cd的路径
建好工程后,构建一次玩玩呗,点击构建详情,等待构建完毕,看到代码风格统计图, Console Output里看到单元测试通过情况,代码覆盖情况。遇到问题:
初始安装后基本都能运行jenkin并看到jenkins web页面,否则重装。修修改改后进程起不来,多看看权限问题,特别是修改jenkins_user
配置的job怎么都不按预期执行,先手动命令行执行,确认无误后查看jenkins环境变量
安装
见Installing Jenkins。它也支持通过Docker安装,真的是紧跟潮流!
需要提的一点是Jenkins比较耗内存,不运行任何构建任务的情况下就吃掉了300多M,再加上构建任务时会占用更多,所以建议服务器的内存至少有1G,512M的话很可能在执行构建任务的时候内存不够用。
访问控制
安装后默认所有人都可以访问,故需要更改访问控制策略,具体见Standard Security Setup。
插件清单
下面是我用到的一些插件:
Git Plugin:使用Git作为源代码管理
SSH plugin:远程ssh登录server执行命令
Parameterized Trigger Plugin:触发其他的job
Cobertura Plugin:代码测试覆盖率报告
Task Scanner Plugin:检测代码中出现的特殊标记(如TODO等)
Violations:代码质量检测,支持pylint、jslint等
ThinBackup:用于备份Jenkins
SCM Sync configuration plugin:将Jenkens的配置变更同步到SCM中
这里只是集中地列举一下,具体的使用会在下面穿插介绍。
测试、Staging部署、Production部署流程
根据本项目的需要,在Jenkins中建立了3个任务:
tm_test:用于执行测试、代码质量检测等
tm_staging_deploy:用于在staging服务器上deploy代码
tm_deploy:用于在production服务器上deploy代码
其中staging服务器用于进行线上测试,staging服务器和production服务器的环境必须保持完全相同(当然,staging服务器配置可以低一些)。
具体的开发、测试、部署流程是:
在开发新功能/修复bug的时候,一般是开新分支;但如果是那种很小的修改,则直接在master上改,这样比较省事儿
新功能开发完成/bug修复后,进行单元测试+人工测试,如果通过,合并到master
每次master有变动后,触发tm_test任务,执行集成的单元测试和代码质量检测,如果OK,则自动触发tm_staging_deploy,部署到staging服务器上
若tm_staging_deploy成功,则登陆到运行在staging服务器的测试网站上,人工测试新功能是否OK/bug是否已修复;若tm_staging_deploy失败,检查失败原因,进行修复,直至成功
若staging人工测试通过,则手动触发tm_deploy,部署到生产服务器上
登录到生产服务器上进行人工测试,若出现问题,进行修复;同时密切关注Sentry发送的告警邮件,争取在第一时间修复错误
比较简单,没有采用Git-Flow/GitHub-Flow,单元测试写得很浅,也没有做代码审查。不过团队规模小,从目前来看,上面的流程是够用的。
下面对这三个任务做较为详细的介绍。
tm_test
该任务用于执行测试、代码质量检测等。
push触发构建
每当项目仓库的master分支有变动时,即会触发tm_test。要做这一点,需要如下步骤:
设置tm_test的Build Triggers为Poll SCM,但不填Schedule
为项目仓库添加Web Hook,URL填写
http://<Jenkins URL>/git/notifyCommit?url=<URL of the Git repository>
参考Stack Overflow。
使用virtualenv配置测试环境
执行测试之前,需要确定Python版本(一般是2.7),然后根据此版本初始化virtualenv。
在构建中添加Execute shell项:
if [ ! -d "venv" ]; then virtualenv -p /usr/bin/python2.7 venvfi
. venv/bin/activate
pip install -i http://pypi.douban.com/simple -r requirements.txt
测试与报告
测试中需要2个库:nose用于执行单元测试,coverage用于统计测试覆盖率。
需要在Jenkins中安装Cobertura Plugin插件,用于生成代码测试覆盖率报告。
然后在构建中添加Execute shell项,输入:
nosetests --with-xunit --with-coverage --cover-package=tm && coverage xml
其中--with-xunit
告诉nose输出JUnit形式的测试报告,--with-coverage
表示同时运行coverage(这个功能相当赞),--cover-package=tm
表示仅对指定的package执行测试覆盖率检测,后面的coverage xml
表示输出xml格式的coverage报告。
然后在构建后操作中,添加如下2项:
Publish JUnit test result report:填写nosetests.xml
Publish Cobertura Coverage Report:填写coverage.xml
这样一来,就可以执行测试,并得到测试报告和测试覆盖率报告啦:
上面的图表都是可点击的,点进去后有代码级的详细报告,非常赞:
绿色的代码行表示已经覆盖到,红色则没有。
代码质量检测
Jenkins有一个蛮不错的代码质量报告插件:Violations,支持非常多的代码测试工具。目前项目中使用Pylint做Python代码质量检测,使用JSHint做JavaScript代码质量检测。
在安装好Pylint后,运行pylint --generate-rcfile > pylintrc
生成配置文件,并将其中的output-format
项的值改为parseable
。
然后在构建中添加2项Execute shell项,
pylint:
pylint tm2 > pylint.xml || exit 0
jshint:
jshint --reporter=jslint $WORKSPACE/tm2/static/js/ > jslint.xml || exit 0
其中的exit 0
是为了告诉Jenkins该命令执行成功。对于jshint来说,report选择jslint,然后需要使用$WORKSPACE
组成绝对路径,否则无法看到源码级的分析报告(是不是一个bug?)。
然后在构建后步骤中添加Violations Report,在对应位置输入jslint.xml和pylint.xml。
最终的图形报告如下,可以看到趋势走向:
源码级别的分析也有:
检测代码中的特殊标注(如TODO)
团队中约定,在代码未完成的地方使用TODO
进行标记,因为PyCharm有一个很好的功能就是可以检测出代码中的所有TODO信息:
Jenkins中也有一个非常棒的插件Task Scanner Plugin用于检测代码中出现的特殊标记,当然,这些特殊标记完全是可以自定义的。
安装完该插件后,在构建后操作中添加一项Scan workspace for open tasks,根据需要填写配置:
然后报告就可以出来啦:
邮件告警
如果构建后状态是unstable或failed,则可以发送邮件告警,及时通知相关负责人进行处理。Jenkins自带SMTP功能,不过需要你提供SMTP服务器。
我使用的是qq邮箱SMTP服务器,挺好用的,目前没有发现拒发的情况。有一点需要注意的是,在配置好SMTP的账户信息后,还需填写系统管理员邮件地址,否则会发送失败,这也是比较容易忽略的地方。
配置好SMTP后,然后在构建后操作中添加E-mail Notification项,填写负责人的邮箱即可。
触发下游任务
如果tm_test构建成功,则需要自动触发tm_staging_deploy任务,这个触发过程是通过插件Parameterized Trigger Plugin来完成的。
在构建后操作中添加Trigger parameterized build on other projects项,选择触发条件为stable,然后填写待出发的任务名称即可。
最后的tm_test任务面板如下:
界面是挺out的,不过很实用。
tm_staging_deploy
这一个job用于将最新代码部署到staging服务器上,我采用的部署方法是通过ssh远程登陆服务器执行命令的方式,需要一个插件SSH plugin。
然后在构建中添加Shell项:
cd /var/www/tmexport MODE=PRODUCTION
git reset --hard HEAD
git pull -fsource venv/bin/activate
pip install -r requirements.txt
python manage.py db upgrade
supervisorctl restart tm
tm_deploy
此任务和tm_staging_deploy基本差不多,不同的地方有2个:(1)目标服务器不同(2)触发方式是手动触发
备份
使用thinBackup进行备份,可设定备份周期。
配置变更同步
除此之外,我还用到了一个很有用的插件SCM Sync configuration plugin,就是把Jenkins的配置(全局配置+各job配置)同步到一个Git仓库中。这样的话,每次配置有变动,都会形成一个commit推送到Git仓库。
这相当于把配置的历史变迁都记录下来,如果哪天Jenkins任务挂了,可以看看配置变更进行排错。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341