移动端Jenkins持续集成攻略（1）
引言：
关于“持续集成”这个词，相信移动端开发的小伙伴们工作中听到不少。但什么是持续集成？为什么要持续集成？恐怕能讲讲清楚的小伙伴并不多。碰巧最近因为工作需要，为公司的移动端搭建了持续集成的环境，借此机会，用三篇的篇幅，为大家简单梳理一下持续集成的概念，以及环境搭建、版本发布中的各种坑。
什么是持续集成？
持续集成指的是，频繁地将代码集成到主干。
它有几个好处：
1. 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
2. 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
3. 通过自动化工具，将测试、编译、发版、上传等手工操作的流程集于一体，让开发人员从琐碎的重复劳动中解放出来。
主要流程
- 提交：流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。
- 测试（第一轮）：代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。
- 构建：通过第一轮测试，代码就可以合并进主干，就算可以交付了。交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。
- 测试（第二轮）：构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
- 部署：通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（ tar filename.tar * ）存档，发到生产服务器。生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。
- 回滚：一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
Jenkins
Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。
安装Jenkins
本人使用的是mac部署持续集成，所以这里只介绍mac上的简单安装流程，其它平台，大同小异，大家可以网上查找资料。
网上关于mac安装Jenkins的教程很多，很多都是直接去Jenkins网站下载安装包，进行傻瓜式安装。本人强烈不推荐这种方式，因为在mac上用这种方式安装会产生一个客户账号，在之后的发布、打包流程中，会遇到一大堆问题。
这里推荐两种方式进行安装：
tomcat + jenkins.war：
这种方式不多介绍了，网上也有很多例子，主要介绍第二种
homebrew 安装 Jenkins：
Homebrew为Mac OS X提供软件包的管理。Homebrew将软件包分装到单独的目录，然后symlink到/usr/local中。Homebrew不会把文件安装到预置目录之外，所以可以将Homebrew安装到任何位置。它完全基于git和ruby。使用gem来安装gems，用brew来搞定他们的依赖包。
命令行输入以下命令
brew install jenkins
如果没有brew工具，可以去官网获取脚本安装，脚本如下：
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
注意在安装完成后会给到你一个Administrator password，务必妥善保存，之后设置需要使用到
终端命令启动
jenkins
之后在浏览器里输入：
http://localhost:8080
看到如下画面，表示之前的安装过程都已成功
还记得刚才记录的Administrator password嘛？现在派上用场了。
之后的安装流程就是简单的根据提示，点下一步即可。
jenkins的插件
Git plugin
Git client plugin
Subversion Plug-in
Subversion Release Manager plugin
Subversion Tagging Plugin
SVN Publisher plugin
SSH Credentials Plugin
Gradle plugin： Android专用
Xcode integration：iOS专用（iOS10貌似还不支持，弃用）
另外如果使用git，需要配置一套公私钥，方式和配置git版本软件方式类似，在
jenkins->Credentials->System->Global credentials (unrestricted)->Add Credentials中，添加一个jenkins本机生成的ssh私钥
然后在git服务器上上传公钥即可
新建一个项目
点击OK后进入到项目的详细配置界面，下面我们详细介绍下配置的每一部分：
General
第一部分没有太多可以讲的内容，输入项目名称和需要的描述即可
源码管理
第二部分源码管理，有git和svn可供选择，这里我们选择git
Repository URL，输入仓库地址
Credentials，输入刚才配置的ssh私钥
Branch Specifier (blank for ‘any’)很好理解，版本库的分支，默认为master
构建触发器
构建触发器顾名思义就是什么时候触发构建，一般常用的是两个：
- Build periodically
- Poll SCM
这两者规则相似，主要区别在于：
Poll SCM，定时检查源码变更（根据SCM软件的版本号），如果有更新就checkout最新code下来，然后执行构建动作。例如：/5 * * * （每5分钟检查一次源码变化）
Build periodically，周期进行项目构建（它不care源码是否发生变化），例如：0 2 * * * （每天2:00 必须build一次源码）
简单讲解下两者表达式的规则：
第一个参数代表的是分钟 minute，取值 0~59；
第二个参数代表的是小时 hour，取值 0~23；
第三个参数代表的是天 day，取值 1~31；
第四个参数代表的是月 month，取值 1~12；
最后一个参数代表的是星期 week，取值 0~7，0 和 7 都是表示星期天；
所以 0 * * * * 表示的就是每个小时的第 0 分钟执行一次构建。不用担心写错，因为你写完一个表达式，下面会有相应的提示，比如我希望每个星期五下午2点进行一次构建，0 14 * * 5，系统会提示：Would last have run at 2017年8月18日 星期五 下午02时00分52秒 CST; would next run at 2017年8月25日 星期五 下午02时00分52秒 CST.可以验证我的表达式符合要求。
构建
整个流程的核心部分，也是可定制化程度最高的部分。iOS和Android各不相同，可以直接手写脚本或添加需要执行的脚本文件，后面的章节会详细介绍iOS和Android的构建
构建后操作
构建后操作也有很多可以定制的内容，比如，测试、邮件等，这里简单介绍一个大部分项目都会用到的邮件功能
要在构建后给相关人员发邮件，首先进到jenkins->插件管理，确认Email Extension Plugin插件已经安装：
如果没有这个插件，安装一下就好了
之后进入jenkins->系统管理->系统设置中，首先配置下管理员的邮箱地址：
然后找到Extended E-mail Notification：
配置SMTP server：发件邮箱的smtp地址，类似于配置一个邮箱客户端；
配置DEefault Recipients：默认收件人，可以是你自己、也可以是产品经理、或者你领导，你看着办吧；
Default Subject，Default Content：默认主题和默认内容，这里类似于设置一个邮件模版，在之后项目的具体邮件配置里，可以使用这里设置的默认值，也可以另行修改。
简单介绍下经常使用的一些变量：
项目名称：$PROJECT_NAME
构建编号：$BUILD_NUMBER
svn版本号：${SVN_REVISION}
构建状态：$BUILD_STATUS
触发原因：${CAUSE}
构建日志地址：${BUILD_URL}
变更集:${JELLY_SCRIPT,template="html"}
其它变量大家可以自行百度。
配置完成之后就可以在构建后操作中添加邮件提醒了，在刚才的构建后邮件提醒的配置里，我基本都使用了默认值，当然你也可以根据自己的需求，配置想要的邮件内容。
后记
关于Jenkins的简单配置就讲到这里，下一篇会详细介绍iOS如何通过Jenkins实现持续集成。