持续化集成工具Jenkins

众所周知，如今App的竞争已经到了用户体验为王，质量为上的白热化阶段。用户们都是很挑剔的。若是一个公司的推广团队好不容易砸了重金推广了一个APP，好不容易有了一些用户，因为一次线上的bug致使一批的用户在使用中纷纷出现闪退bug，轻则，极可能前期推广砸的钱都白费了，重则，口碑很差，将来也提高不起用户量来了。静下心来分析一下问题的缘由，无外乎就是质量没有过关就上线了。除去主观的一些因素，很大部分的客观因素我以为能够被咱们防范的。根据大神们提出的一套开发规范建议，CI + FDD，就能够帮助咱们极大程度的解决客观因素。本文接下来主要讨论 Continuous Integration 持续集成（简称CI）

目录

1.为何咱们须要持续集成

2.持续化集成工具——Jenkins

3.iOS自动化打包命令——xcodebuild + xcrun 和 fastlane - gym 命令

4.打包完成自动化上传 fir / 蒲公英 第三方平台

5.完整的持续集成流程

6.Jenkins + Docker

1、为何咱们须要持续集成

谈到为何须要的问题，咱们就须要从什么是来讲起。那什么是持续集成呢。

持续集成是一种软件开发实践：许多团队频繁地集成他们的工做，每位成员一般进行平常集成，进而天天会有多种集成。每一个集成会由自动的构建（包括测试）来尽量快地检测错误。许多团队发现这种方法能够显著的减小集成问题而且可使团队开发更加快捷。

CI是一种开发实践。实践应该包含3个基本模块，一个能够自动构建的过程，自动编译代码，能够自动分发，部署和测试。一个代码仓库，SVN或者Git。最后一个是一个持续集成的服务器。经过持续集成，可让咱们经过自动化等手段高频率地去获取产品反馈并响应反馈的过程。

那么持续集成能给咱们带来些什么好处呢？这里推荐一篇文章，文章中把Continuous integration (CI) and test-driven development (TDD)分红了12个步骤。然而带来的好处成倍增长，有24点好处。

我来讲说用了CI之后带来的一些深有体会的优势。

1. 缩减开发周期，快速迭代版本

每一个版本开始都会估算好开发周期，可是总会由于各类事情而延期。这其中包括了一些客观因素。因为产品线增多，迭代速度愈来愈快，给测试带来的压力也愈来愈大。若是测试都在开发彻底开发完成以后再来测试，那就会影响很长一段时间。这时候因为集成晚就会严重拖慢项目节奏。若是能尽早的持续集成，尽快进入上图的12步骤的迭代环中，就能够尽早的暴露出问题，提前解决，尽可能在规定时间内完成任务。

2. 自动化流水线操做带来的高效

其实打包对于开发人员来讲是一件很耗时，并且没有很大技术含量的工做。若是开发人员一多，相互改的代码冲突的概率就越大，加上没有产线管理机制，代码仓库的代码质量很难保证。团队里面会花一些时间来解决冲突，解决完了冲突还须要本身手动打包。这个时候若是证书又不对，又要耽误好长时间。这些时间其实能够用持续集成来节约起来的。一天两天看着很少，可是按照年的单位来计算，能够节约不少时间！

3. 随时可部署

有了持续集成之后，咱们能够以天为单位来打包，这种高频率的集成带来的最大的优势就是能够随时部署上线。这样就不会致使快要上线，处处是漏洞，处处是bug，手忙脚乱弄完之后还不能部署，严重影响上线时间。

4. 极大程度避免低级错误

咱们能够犯错误，可是犯低级错误就很不该该。这里指的低级错误包括如下几点：编译错误，安装问题，接口问题，性能问题。

以天为单位的持续集成，能够很快发现编译问题，自动打包直接没法经过。打完包之后，测试扫码没法安装，这种问题也会当即被暴露出来。接口问题和性能问题就有自动化测试脚原本发现。这些低级问题由持续集成来暴露展示出来，提醒咱们避免低级错误。

2、持续化集成工具——Jenkins

Jenkins 是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专一于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展现项目构建的趋势和稳定性。

根据官方定义，Jenkins有如下的用途：

• 构建项目

• 跑测试用例检测bug

• 静态代码检测

• 部署

关于这4点，实际使用中仍是比较方便的：

1.构建项目自动化打包能够省去开发人员好多时间，重要的是，Jenkins为咱们维护了一套高质量可用的代码，并且保证了一个纯净的环境。咱们常常会出现因为本地配置出错而致使打包失败的状况。如今Jenkins就是一个公平的评判者，它没法正确的编译出ipa，那就是有编译错误或者配置问题。开发人员不必去争论本地是能够运行的，拉取了谁谁谁的代码之后就不能运行了。共同维护Jenkins的正常编译，由于Jenkins的编译环境比咱们本地简单的多，它是最纯净无污染的编译环境。开发者就只用专一于编码。这是给开发者带来的便利。

2.这个能够用来自动化测试。在本地生成大批的测试用例。天天利用服务器不断的跑这些用例。天天每一个接口都跑一遍。看上去不必，可是实际上今天运行正常的系统，极可能因为今天的代码改动，明天就出现问题了。有了Jenkins能够以天为单位的进行回归测试，代码只要有改动，Jenkins就把全部的回归测试的用例所有都跑一遍。在项目工期紧张的状况下，不少状况测试都不是很重视回归测试，毕竟极可能测一遍以后是徒劳的“无用功”。然而因为回归测试不及时，就致使到最后发版的时候系统不可用了，这时候回头查找缘由是比较耗时的，查看提交记录，看到上百条提交记录，排查起来也是头疼的事情。以天为单位的回归测试能当即发现问题。测试人员天天能够专一按单元测试，一周手动一次回归测试。这是给测试者带来的便利。

3.这个是静态代码分析，能够检测出不少代码的问题，好比潜在的内存泄露的问题。因为Jenkins所在环境的纯净，仍是能够发现一些咱们本地复杂环境没法发现的问题，进一步的提升代码质量。这是给质检带来的便利。

4.随时部署。Jenkins在打包完成以后能够设定以后的操做，这个时候每每就是提交app到跑测试用例的系统，或者部署到内测平台生成二维码。部署中不能安装等一些低级问题随之当即暴露。测试人员也只须要扫一下二维码便可安装，很方便。这也算是给测试带来的便利。

如下的例子以2016-07-24 22:35的Weekly Release 2.15的版本为例。

咱们来开始安装Jenkins。从官网https://jenkins.io/ 上下载最新的pkg安装包。

也能够下载jenkins.war, 而后运行Java -jar jenkins.war，进行安装。

安装完成以后，Safari可能会自动打开，若是没有自动打开，打开浏览器，输入http://localhost:8080

这个时候可能会报一个错误。若是出现了这面的问题。出现这个问题的缘由就是Java环境有问题，从新Java环境便可。

这个时候若是你重启电脑会发现Jenkins给你新增了一个用户，名字就叫Jenkins，不过这个时候你不知道密码。你可能会去试密码，确定是是不对的，由于初始密码很复杂。这个时候正确作法是打开http://localhost:8080 会出现下图的重设初始密码的界面。

按照提示，找到/Users/Shared/Jenkins/Home/ 这个目录下，这个目录虽然是共享目录，可是有权限的，非Jenkins用户/secrets/目录是没有读写权限的。

打开initialAdminPassword文件，复制出密码，就能够填到网页上去重置密码了。以下图

一路安装过来，输入用户名，密码，邮件这些，就算安装完成了。

仍是继续登陆localhost:8080 ，选择“系统管理”——“管理插件”，咱们要先安装一些辅助插件。

安装GitLab插件

由于咱们用的是GitLab来管理源代码，Jenkins自己并无自带GitLab插件，因此咱们须要依次选择 系统管理->管理插件，在“可选插件”中选中“GitLab Plugin”和“Gitlab Hook Plugin”这两项，而后安装。

安装Xcode插件

同安装GitLab插件的步骤同样，咱们依次选择系统管理->管理插件，在“可选插件”中选中“Xcode integration”安装。

安装完了这个，咱们就能够配置一个构建项目了。

点击新建好的项目，进来配置一下General参数。

这里能够设置包的保留天数还有天数。

接着设置源码管理。

因为如今我用到的是GitLab，先配置SSH Key，在Jenkins的证书管理中添加SSH。在Jenkins管理页面，选择“Credentials”，而后选择“Global credentials (unrestricted)”，点击“Add Credentials”，以下图所示，咱们填写本身的SSH信息，而后点击“Save”，这样就把SSH添加到Jenkins的全局域中去了。

若是正常的配置正确的话，是不会出现下图中的那段红色的警告。若是有下图的提示，就说明Jenkins尚未连通GitLab或者SVN，那就请再检查SSH Key是否配置正确。

构建触发器设置这里是设置自动化测试的地方。这里涉及的内容不少，暂时我也没有深刻研究，这里暂时先不设置。有自动化测试需求的能够好好研究研究这里的设置。

不过这里有两个配置仍是须要是配置的

Poll SCM (poll source code management) 轮询源码管理

须要设置源码的路径才能起到轮询的效果。通常设置为相似结果： 0/5 每5分钟轮询一次

Build periodically (定时build)

通常设置为相似： 00 20 * 天天 20点执行定时build 。固然二者的设置都是同样能够通用的。

格式是这样的

分钟(0-59) 小时(0-23) 日期(1-31) 月(1-12) 周几(0-7,0和7都是周日)（更加详细的设置看这里）

构建环境设置

iOS打包须要签名文件和证书，因此这部分咱们勾选“Keychains and Code Signing Identities”和“Mobile Provisioning Profiles”。

这里咱们又须要用到Jenkins的插件，在系统管理页面，选择“Keychains and Provisioning Profiles Management”。

进入Keychains and Provisioning Profiles Management页面，点击“浏览”按钮，分别上传本身的keychain和证书。上传成功后，咱们再为keychain指明签名文件的名称。点击“Add Code Signing Identity”，最后添加成功后以下图所示：

注意：我第一次导入证书和Provisioning Profiles文件，就遇到了一点小“坑”，我当时觉得是须要证书，可是这里须要的Keychain，并非cer证书文件。这个Keychain其实在/Users/管理员用户名/Library/keychains/login.keychain,当把这个Keychain设置好了以后，Jenkins会把这个Keychain拷贝到/Users/Shared/Jenkins/Library/keychains这里，(Library是隐藏文件)。Provisioning Profiles文件也直接拷贝到/Users/Shared/Jenkins/Library/MobileDevice文件目录下。

这样Adhoc证书和签名文件就在Jenkins中配置好了，接下来咱们只须要在item设置中指定相关文件便可。

回到咱们新建的item，找到构建环境，按下图选好本身的相关证书和签名文件。

接下来在进行构建的设置

咱们这里选择执行一段打包脚本。脚本在下一章节详细的讲解。

构建后操做

这里咱们选择Execute a set of scripts，这里也是一个脚本，这个脚本用来上传自动打包好的ipa文件。脚本在第四章节有详细的讲解。

至此，咱们的Jenkins设置就所有完成了。点击构建，就会开始构建项目了。

构建一次，各个颜色表明的意义以下：

天气的晴雨表表明了项目的质量，这也是Jenkins的一个特点。

若是构建失败了，能够去查看Console Output能够查看log日志。

3、iOS自动化打包命令——xcodebuild + xcrun 和 fastlane - gym 命令

在平常开发中，打包是最后上线不可缺乏的环节，若是须要把工程打包成 ipa 文件，一般的作法就是在 Xcode 里点击 「Product -> Archive」，当整个工程 archive 后，而后在自动弹出的 「Organizer」 中进行选择，根据须要导出 ad hoc，enterprise 类型的 ipa 包。虽然Xcode已经能够很完美的作到打包的事情，可是仍是须要咱们手动点击5，6下。加上咱们如今须要持续集成，用打包命令自动化执行就顺其天然的须要了。

1. xcodebuild + xcrun命令

Xcode为咱们开发者提供了一套构建打包的命令，就是xcodebuild

和xcrun命令。xcodebuild把咱们指定的项目打包成.app文件，xcrun将指定的.app文件转换为对应的.ipa文件。

具体的文档以下：xcodebuild官方文档、xcrun官方文档

1 2 3 4 5 6 7 8 9 10 11 12 13

NAME xcodebuild – build Xcode projects and workspaces SYNOPSIS 1. xcodebuild [-project name.xcodeproj] [[-target targetname] … | -alltargets] [-configuration configurationname] [-sdk [sdkfullpath | sdkname]] [action …] [buildsetting=value …] [-userdefault=value …] 2. xcodebuild [-project name.xcodeproj] -scheme schemename [[-destination destinationspecifier] …] [-destination-timeout value] [-configuration configurationname] [-sdk [sdkfullpath | sdkname]] [action …] [buildsetting=value …] [-userdefault=value …] 3. xcodebuild -workspace name.xcworkspace -scheme schemename [[-destination destinationspecifier] …] [-destination-timeout value] [-configuration configurationname] [-sdk [sdkfullpath | sdkname]] [action …] [buildsetting=value …] [-userdefault=value …] 4. xcodebuild -version [-sdk [sdkfullpath | sdkname]] [infoitem] 5. xcodebuild -showsdks 6. xcodebuild -showBuildSettings [-project name.xcodeproj | [-workspace name.xcworkspace -scheme schemename]] 7. xcodebuild -list [-project name.xcodeproj | -workspace name.xcworkspace] 8. xcodebuild -exportArchive -archivePath xcarchivepath -exportPath destinationpath -exportOptionsPlist path 9. xcodebuild -exportLocalizations -project name.xcodeproj -localizationPath path [[-exportLanguage language] …] 10. xcodebuild -importLocalizations -project name.xcodeproj -localizationPath path

上面10个命令最主要的仍是前3个。

接下来来讲明一下参数：

-project -workspace：这两个对应的就是项目的名字。若是有多个工程，这里又没有指定，则默认为第一个工程。

-target：打包对应的targets，若是没有指定这默认第一个。

-configuration：若是没有修改这个配置，默认就是Debug和Release这两个版本，没有指定默认为Release版本。

-buildsetting=value ...：使用此命令去修改工程的配置。

-scheme：指定打包的scheme。

上面这些是最最基本的命令。

上面10个命令的第一个和第二个里面的参数，其中 -target

和 -configuration 参数可使用 xcodebuild -list

得到，-sdk 参数可由 xcodebuild -showsdks

得到，[buildsetting=value ...] 用来覆盖工程中已有的配置。可覆盖的参数参考官方文档：Xcode Build Setting Reference。

1 2 3 4 5 6 7 8 9 10 11 12 13 14

build Build the target in the build root (SYMROOT). This is the default action, and is used if no action is given. analyze Build and analyze a target or scheme from the build root (SYMROOT). This requires specifying a scheme. archive Archive a scheme from the build root (SYMROOT). This requires specifying a scheme. test Test a scheme from the build root (SYMROOT). This requires specifying a scheme and optionally a destination. installsrc Copy the source of the project to the source root (SRCROOT). install Build the target and install it into the target’s installation directory in the distribution root (DSTROOT). clean Remove build products and intermediate files from the build root (SYMROOT).

上面第3个命令就是专门用来打带有Cocopods的项目，由于这个时候项目工程文件再也不是xcodeproj了，而是变成了xcworkspace了。

再来讲说xcrun命令。

1 2 3 4 5 6 7 8 9

Usage: PackageApplication [-s signature] application [-o output_directory] [-verbose] [-plugin plugin] || -man || -help Options: [-s signature]: certificate name to resign application before packaging [-o output_directory]: specify output filename [-plugin plugin]: specify an optional plugin -help: brief help message -man: full documentation -v[erbose]: provide details during operation

参数很少，使用方法也很简单，xcrun -sdk iphoneos -v PackageApplication + 上述一些参数。

参数都了解以后，咱们就来看看该如何用了。下面这个是使用了xcodebuild + xcrun命令写的自动化打包脚本

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

# 工程名 APP_NAME="YourProjectName" # 证书 CODE_SIGN_DISTRIBUTION="iPhone Distribution: Shanghai ******* Co., Ltd." # info.plist路径 project_infoplist_path="./${APP_NAME}/Info.plist" #取版本号 bundleShortVersion=$(/usr/libexec/PlistBuddy -c "print CFBundleShortVersionString" "${project_infoplist_path}") #取build值 bundleVersion=$(/usr/libexec/PlistBuddy -c "print CFBundleVersion" "${project_infoplist_path}") DATE="$(date +%Y%m%d)" IPANAME="${APP_NAME}_V${bundleShortVersion}_${DATE}.ipa" #要上传的ipa文件路径 IPA_PATH="$HOME/${IPANAME}" echo ${IPA_PATH} echo "${IPA_PATH}">> text.txt //下面2行是没有Cocopods的用法 echo "=================clean=================" xcodebuild -target "${APP_NAME}"  -configuration 'Release' clean echo "+++++++++++++++++build+++++++++++++++++" xcodebuild -target "${APP_NAME}" -sdk iphoneos -configuration 'Release' CODE_SIGN_IDENTITY="${CODE_SIGN_DISTRIBUTION}" SYMROOT='$(PWD)' //下面2行是集成有Cocopods的用法 echo "=================clean=================" xcodebuild -workspace "${APP_NAME}.xcworkspace" -scheme "${APP_NAME}"  -configuration 'Release' clean echo "+++++++++++++++++build+++++++++++++++++" xcodebuild -workspace "${APP_NAME}.xcworkspace" -scheme "${APP_NAME}" -sdk iphoneos -configuration 'Release' CODE_SIGN_IDENTITY="${CODE_SIGN_DISTRIBUTION}" SYMROOT='$(PWD)' xcrun -sdk iphoneos PackageApplication "./Release-iphoneos/${APP_NAME}.app" -o ~/"${IPANAME}"

2. gym 命令

说到gym，就要先说一下fastlane。

fastlane是一套自动化打包的工具集，用 Ruby 写的，用于 iOS 和 Android 的自动化打包和发布等工做。gym是其中的打包命令。

fastlane的官网看这里, fastlane的github看这里。

要想使用gym，先要安装fastlane。

1	sudo gem install fastlane --verbose

• fastlane包含了咱们平常编码以后要上线时候进行操做的全部命令。

• deliver：上传屏幕截图、二进制程序数据和应用程序到AppStore

• snapshot：自动截取你的程序在每一个设备上的图片

• frameit：应用截屏外添加设备框架

• pem：能够自动化地生成和更新应用推送通知描述文件

• sigh：生成下载开发商店的配置文件

• produce：利用命令行在iTunes Connect建立一个新的iOS app

• cert：自动建立iOS证书

• pilot：最好的在终端管理测试和创建的文件

• boarding：很容易的方式邀请beta测试

• gym：创建新的发布的版本，打包

• match：使用git同步你成员间的开发者证书和文件配置

• scan：在iOS和Mac app上执行测试用例

整个发布过程能够用fastlane描述成下面这样

1 2 3 4 5 6 7 8 9 10 11

lane :appstore do   increment_build_number   cocoapods   xctool   snapshot   sigh   deliver   frameit   sh "./customScript.sh"   slack end

Ps：这里可能你们还会听过一个命令叫 xctool

xctool是官方xcodebuild命令的一个加强实现，输出的内容比xcodebuild直观可读得多。经过brew便可安装。

1	brew install xctool

使用gym自动化打包，脚本以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

#计时 SECONDS=0 #假设脚本放置在与项目相同的路径下 project_path=$(pwd) #取当前时间字符串添加到文件结尾 now=$(date +"%Y_%m_%d_%H_%M_%S") #指定项目的scheme名称 scheme="DemoScheme" #指定要打包的配置名 configuration="Adhoc" #指定打包所使用的输出方式，目前支持app-store, package, ad-hoc, enterprise, development, 和developer-id，即xcodebuild的method参数 export_method='ad-hoc' #指定项目地址 workspace_path="$project_path/Demo.xcworkspace" #指定输出路径 output_path="/Users/your_username/Documents/" #指定输出归档文件地址 archive_path="$output_path/Demo_${now}.xcarchive" #指定输出ipa地址 ipa_path="$output_path/Demo_${now}.ipa" #指定输出ipa名称 ipa_name="Demo_${now}.ipa" #获取执行命令时的commit message commit_msg="$1" #输出设定的变量值 echo "===workspace path: ${workspace_path}===" echo "===archive path: ${archive_path}===" echo "===ipa path: ${ipa_path}===" echo "===export method: ${export_method}===" echo "===commit msg: $1===" #先清空前一次build gym --workspace ${workspace_path} --scheme ${scheme} --clean --configuration ${configuration} --archive_path ${archive_path} --export_method ${export_method} --output_directory ${output_path} --output_name ${ipa_name} #输出总用时 echo "===Finished. Total time: ${SECONDS}s==="

4、打包完成自动化上传 fir / 蒲公英 第三方平台

要上传到 fir / 蒲公英 第三方平台，都须要注册一个帐号，得到token，以后才能进行脚本化操做。

1. 自动化上传fir

安装fir-clifir的命令行工具

须要先装好ruby再执行

1 2 3

gem install fir-cli #上传到fir fir publish ${ipa_path} -T fir_token -c "${commit_msg}"

2.自动化上传蒲公英

1 2 3 4 5 6 7 8 9 10

#蒲公英上的User Key uKey="7381f97070*****c01fae439fb8b24e" #蒲公英上的API Key apiKey="0b27b5c145*****718508f2ad0409ef4" #要上传的ipa文件路径 IPA_PATH=$(cat text.txt) rm -rf text.txt #执行上传至蒲公英的命令 echo "++++++++++++++upload+++++++++++++" curl -F "file=@${IPA_PATH}" -F "uKey=${uKey}" -F "_api_key=${apiKey}" http://www.pgyer.com/apiv1/app/upload

5、完整的持续集成流程

通过上面的持续化集成，如今咱们就拥有了以下完整持续集成的流程

6、Jenkins + Docker

关于Jenkins的部署，实际上是分如下两种：

单节点（Master）部署

这种部署适用于大多数项目，其构建任务较轻，数量较少，单个节点就足以知足平常开发所需。

多节点(Master-Slave)部署

一般规模较大，代码提交频繁（意味着构建频繁），自动化测试压力较大的项目都会采起这种部署结构。在这种部署结构下，Master一般只充当管理者的角色，负责任务的调度，slave节点的管理，任务状态的收集等工做，而具体的构建任务则会分配给slave节点。一个Master节点理论上能够管理的slave节点数是没有上限的，但一般随着数量的增长，其性能以及稳定性就会有不一样程度的降低，具体的影响则因Master硬件性能的高低而不一样。

可是多节点部署又会有一些缺陷，当测试用例变得海量之后，会形成一些问题，因而有人设计出了下面这种部署结构，Jenkins + Docker

因为笔者如今的项目还处于单节点（Master）部署，关于多节点(Master-Slave)部署也没有实践经验，改进版本的Docker更是没有接触过，可是若是有这种海量测试用例，高压力的大量复杂的回归测试的需求的，那推荐你们看这篇文章。