两年前我入职现在工作的地方后第一次knowledge share一位同事分享了jenkins. 两年后的现在他已经是老同事并且也成为了前同事. 为了纪念离开的他我想试试折腾一下jenkins.(炉石的火车王也叫jenkins哦).

背景故事

先来讲讲这次ci的需求. 这里有一个web项目一个安卓项目. web项目又被作为portal, 当时临时满足需求的做法是手动从mobile项目打包, 把包扔到web项目里提到git上. 很明显手动打包和把build结果扔进git是极为粗糙野蛮的. 那么我们就需要优雅地完成: 在web项目build成功后拉取mobile项目源码打包并把打包结果放到web项目的相应位置, 再停起web服务.

之前没有操作过jenkins, 只在build博客的时候用的travis.ci, 这次使用jenkins的体验非常好, 问题都出在运维方面, 没有出在jenkins上. 这归功于这位前同事的分享和无数后端同事的工作, 包含但不仅包含软件安装, 软件配置, 账户配置, 免密登录配置这些需要花很多精力的工作.

jenkins项目介绍

我的理解非常浅, 我的使用体验是一个项目的核心就是配置, 配置好以后点一下立即构建就好了. 我们使用的都是git项目, jenkins触发构建以后会拉一次git的代码并放在对应的文件夹下(如果没有则创建). 然后根据配置在自己的工作空间里进行持续集成.

于是我新建了个项目, 选择完全自定义, 开始进入配置.

配置

jenkins的配置非常简单. 我们从头到尾全过一遍.

一开始是项目的名字描述什么的.

然后有一个github项目的复选项, 打上勾, 填上git地址, 每次触发构建jenkins就会把源码从这个地址pull到项目名对应的文件夹下了.

源码管理

在这里填写git地址, 还有一个svn选项. 填上地址, 然后当然项目是有权限的, 那么添加你的账号来获得权限.

构建触发器与构建环境

构建触发器: 选择一些触发的条件, 比如其他项目构建好/git有新的提交/周期构建. 我这里什么都没选, 也就是只有当在页面上点击立即构建的情况才会去构建.

构建环境: 提供了一些创造构建环境的快捷方式, 比如: 构建前清空工作区, 构建前ssh连上远程机器. 这些其实都可以在构建的时候操作.

构建

这里是核心地方. 一般ci的功能: lint/test/build都在这里做吧. 可以分成n个步骤, 点击增加构建步骤来增加步骤, 步骤里可以直接执行shell, 也可以ssh到远程来执行shell, 或者执行lint等等常用的操作.

我的构建分2个步骤.

  1. 本地执行shell: 走到这里的时候代码已经被pull到工作空间了, 只要执行yarn和打包apk的操作就行了. 执行好以后把打好的包scp到目标机器上.
  2. 远程执行shell: 设置远程机器的ip和用户并免密登录就可以了. 执行到这里顺利的话目标机器已经有了apk包了, 切到web应用的目录, 停止服务, 把apk拷到对应的目录, 启动服务.

构建的过程就搞定了.

构建后操作

这里是构建后执行的操作, 有发布文档/发布git/清空工作空间等. 有一个是我们要设置的: Build other projects. 不是在这里设置, 在web项目的构建后操作里点上这个, 构建完成触发我新写的这个项目就ok啦.

遇到的非jenkins问题流水账

本以为这个工作很快, 然后在apk打包的时候碰到问题卡了一整天, jenkins的机器是ubuntu14, 平时工作的是mac, 先不说os, build环境也是没装, 于是下了安卓sdk, 安卓sdk工具好像也推荐gui(android studio), cli还deprecated了. 安装好以后build一直报各种错. 本来在build的时候加—debug后缀, 毫无意义, 最后加了—stacktrace后缀终于得到了有用的信息, 见招拆招, 最后顺利地打包了~

感想: jenkins与travis.ci比较

只说自己的感受: jenkins比travis.ci方便许多, 不排除有了travis.ci的经验的关系.

因为travis.ci是公有ci的关系, 每次环境都是新的, 所以调试和环境配置都成了麻烦. jenkins直接ssh到jenkins的机器上一顿操作就行了, travis.ci还要设置环境. 调试shell的时候也是直接敲就行了.

另一个jenkins的好处: 更小白化, 对于常用的操作进行封装, 只要点点就行了不用写shell.

travis.ci好处: ci过程可以放到git里. (所以无法避免对shell和os的要求更高)