iOS Jenkins+ cocoapods + fastlan

2017-06-14 本文已影响873人狼凤皇

iOS 脚本自动化打包

1.为什么需要持续集成（Continuous Integration）CI

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

3.iOS自动化打包命令——xcodebuild + xcrun 和 fastlane – gym 命令 (Fastlane 2.38 发布，首次支持 Xcode 9)

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

5.完整的持续集成流程

6.Jenkins + Docker

7.自动化测试

Jenkins 上完成基于 KIF 的 UI 自动化持续集成搭建

一、持续集成

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

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

优点

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

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

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

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

3. 随时可部署

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

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

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

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

二、jenkins

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

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

构建项目

跑测试用例检测bug

静态代码检测

部署

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

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

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

3.这个是静态代码分析，可以检测出很多代码的问题，比如潜在的内存泄露的问题。由于Jenkins所在环境的纯净，还是可以发现一些我们本地复杂环境无法发现的问题，进一步的提高代码质量。这是给质检带来的便利。

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

Jenkins安装方式(Mac)

前提：必须有java环境

1.直接下载安装安装---jenkins

2.通过Homebrew使用命令行安装

（1）安装Homebrew

ruby -e "$(curl -fsSLhttps://raw.githubusercontent.com/Homebrew/install/master/install)"

（2）安装Jenkins

brew install jenkins

（3）启动Jenkins

jenkins

3.tomcat+jenkins（jenkins 运行在tomcat上)

tomcat:必须得赋予一个用户

localhost:8080/jenkins/

jenkins 默认配置http://localhost:8080初次安装进入会有密码提示路径（查找路径进入，复制密码填写，进入后建立一个用户然后以新建的用户进行登陆）

sudo vim /var/root/.jenkins/secrets/initialAdminPassword

重启服务 java -jar jenkins.war --httpPort=8888

4.jenkins 插件(系统管理------>管理插件)

1、Xcode integration

2、GIT plugin

3、GitLab Plugin

4、Gitlab Hook Plugin

5、Keychains and Provisioning Profiles Management

6、CocoaPods Jenkins Integration

5.钥匙串、配置文件管理（系统管理------>Keychains and Provisioning Profiles Management）

1.login.keychain 【位置 ~/Library/Keychains/login.keychain】

2.iPhone Developer 名称

3.iPhone Distribution 名称

4.本机配置文件路径【位置 /Users/<用户名>/Library/MobileDevice/Provisioning Profiles】

5.打包测试包用的的配置文件ad_hoc

6.打包正式上线环境用到的配置文件distribution

注意：1、5、6 需要上传文件然后upload

2、3 只需要把名称填进去就可以了（如下图）

到此iOS 打包环境配置已经完成

6.【jenkins iOS项目配置】

三、iOS自动化打包命令

1.xcodebuild + xcrun

2.fastlane – gym linGan_dev_ipa.sh(自己项目中用到的)

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

要上传到 fir / 蒲公英第三方平台，都需要注册一个账号，获得token，之后才能进行脚本化操作。

1. 自动化上传fir

安装fir-clifir的命令行工具（需要先装好ruby再执行）

gem install fir-cli

#上传到fir

fir publish ${ipa_path} -T fir_token -c "${commit_msg}"

2.自动化上传蒲公英

#蒲公英上的User Key

uKey="7381f97070*****c01fae439fb8b24e"

#蒲公英上的API Key

apiKey="0b27b5c145*****718508f2ad0409ef4"

#要上传的ipa文件路径

IPA_PATH=$(cat text.txt)

#执行上传至蒲公英的命令

echo "++++++++++++++upload+++++++++++++"

curl -F "file=@${IPA_PATH}" -F "uKey=${uKey}" -F "_api_key=${apiKey}"

五. 完整的持续集成流程

经过上面的持续化集成，现在我们就拥有了如下完整持续集成的流程

六. Jenkins + Docker

关于Jenkins的部署，其实是分以下两种：

单节点（Master）部署

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

多节点(Master-Slave)部署

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

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