原先搭建这套东西其实没多少事,可是受人邀请,仍是写篇文章防止后来人踏坑吧。html
持续集成系统(CI)想必看文章的应该都知道是什么东西,应该都清楚,若是不太明白的,移步 https://en.wikipedia.org/wiki/Continuous_integrationjava
总结起来其实也很简单: 把构建和发布的问题自动化、简单化。linux
你能够想象这么一个场景:git
当你的代码写完后,敲入一个git push,CI 系统自动帮你
compile
/test
/archive
/publish
而你只须要坐在那边,喝一杯java
就够了。程序员
对于爱“偷懒”的程序员来讲,这是十分惬意的事情,由于咱们最自豪的就是解放本身的生产力,让本身不要花时间去作一些无心义的事情,既伤神又费力。docker
固然,在当今的时代,咱们拥有docker这种神器,其实安装这件事情,也已经很傻瓜化了。windows
OK,那么简单几行命令搞定xcode
docker pull gitlab/gitlab-ce docker run -d -P gitlab/gitlab-ce
若是须要进行端口映射,请参考-p
参数bash
当你配置好以后,访问你的母鸡地址,出现这个页面就是部署好了,而后就是注册和登录的事情。app
Gitlab
最新版中已经将CI
系统内置了,因此咱们只须要部署runner
便可。runner
是啥概念?由于咱们的CI
在跑的时候,不该该被它的安装环境所限制,好比咱们把CI
安装在linux
下,这时候想打包iOS
可能就办不到了,因此Gitlab CI
就把整个 CI 拆成两个部分,一个server
和一个runner
,现在server
也都内置到Gitlab
里去了,因此安装好了就行了。
那么咱们能够在一台 Mac 上安装好runner
连上Gitlab
便可。
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
这个传送门是到gitlab-ci-multi-runner
的,上面有介绍了如何安装使用runner
。可是要注意的是,它通常都会在linux
环境下使用的比较多,而在windows
和OS X
下好像并无,这也是为何我此次踩坑的缘由了。
首先,咱们下载好gitlab-ci-multi-runner
的二进制文件,咱们知道要把它作成服务的话,须要如下步骤:
register
install
start
register
就是告诉server
这个runner
的存在,install
是安装成系统服务,start
就是启动服务啦~ 这3个命令很简单。
那么,咱们先执行gitlab-ci-multi-runner
的run
看,它是不安装系统服务,直接跑的命令。
好嘛,一来就发现刺眼的3个warning
,对,就是这3个warning
把我带入了深渊。 它的意思很明确,要求咱们用root
身份执行这个命令。
可是!!
root
是不能在Xcodearchive
完以后 进行codesign
的!即时你在gitlab-ci-multi-runner
指定了--user
也不行!!
因此,咱们在这里要作的就是无视这3个warning,转而用咱们本身用户的身份进行安装服务
gitlab-ci-multi-runner install --config xxxx -d /tmp gitlab-ci-multi-runner start
便可,-d
是指定runner
的工做目录,也就是把代码库clone
下来的目录,我指定到了/tmp
文件夹。
xcodebuild
就是 Xcode
的命令行工具能提供 编译/测试/打包 等功能,咱们只须要指定workspace
和scheme
或者project
便可编译,指定好Provisioning Profile
等证书文件就能打包,可是它的输出很是很差看,此次咱们使用了xctool
这个工具,它是facebook
开发的,用来美化xcodebuild
输出的一个辅助工具,我的很喜欢它的输出样式。
安装xctool
也很简单:
brew install xctool
来一个使用xctool
的样例:
xctool -workspace SegmentFault.xcworkspace -scheme $PRERELEASE_SCHEME archive -archivePath ./build/SegmentFault.xcarchive
这里咱们指定了workspace
和scheme
(我用环境变量代替),而后指定了导出xcarchive
中间格式的路径,那么咱们导出成xcarchive
就完成了,若是要导出成IPA
,须要这个中间产物。
而后导出IPA,咱们使用xcodebuild
命令:
xcodebuild -exportArchive -archivePath ./build/SegmentFault.xcarchive -exportPath ./build -exportOptionsPlist ./ExportOptions.plist CODE_SIGN_IDENTITY="$CODE_SIGN_IDENTITY" PROVISIONING_PROFILE="$PROVISIONING_PROFILE"
ExportOptions.plist
里面指定了一些选项,好比导出的环境(AppStore/AdHoc/Developer等),其实就是咱们在Xcode
/Origanizer
中配置到的那些:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>compileBitcode</key> <false/> <key>method</key> <string>ad-hoc</string> </dict> </plist>
执行完xcodebuild
就获得了咱们的ipa
文件,若是是手工敲命令的话,就是这么几个步骤。
那么如何让CI跑这些命令呢?这时候咱们就须要使用Gitlab CI
中的.gitlab.yml
这个文件了,Gitlab
只要检测到有这个文件,就会开始构建你的项目,具体的使用说明能够看这里:http://docs.gitlab.com/ce/ci/yaml/README.html
那么贴一个个人样例
variables: PRERELEASE_SCHEME: "SegmentFault_Alpha" CODE_SIGN_IDENTITY: "xxxxxx" PROVISIONING_PROFILE: "xxxxx" LANG: "en_US.UTF-8" stages: - archive - upload archive: stage: archive script: - pod install - carthage update --platform iOS - xctool -workspace SegmentFault.xcworkspace -scheme $PRERELEASE_SCHEME archive -archivePath ./build/SegmentFault.xcarchive - "xcodebuild -exportArchive -archivePath ./build/SegmentFault.xcarchive -exportPath ./build -exportOptionsPlist ./ExportOptions.plist CODE_SIGN_IDENTITY=\"$CODE_SIGN_IDENTITY\" PROVISIONING_PROFILE=\"$PROVISIONING_PROFILE\"" only: - fir artifacts: expire_in: '1 day' paths: - ./build/$PRERELEASE_SCHEME.ipa upload: stage: upload only: - fir script: - fir publish -T xxxxxx -c ./CHANGELOG ./build/$PRERELEASE_SCHEME.ipa dependencies: - archive
这里咱们看到stages
总共作了2个任务archive
和upload
,我在archive
的定义中,执行了4条命令,分别是pod
相关,carthage
相关,而后是xcodebuild
相关命令进行打包,iOS程序员应该都知道pod
和carthage
吧,是在打包前给咱们安装依赖的,依赖安装好了才能构建,这是常识。
在这个步骤完成以后,咱们执行upload
任务,就是调用fir-cli
这个工具,把咱们的应用发布到fir.im
上,给测试人员分发测试。
好了,我终于从在Xcode
中进行打包,导出后到fir.im
上进行上传ipa
操做,并写Change Log
任务这么一系列很繁琐的工做中解脱了,之后我就只需在fir
这个分支上进行一次push
,那么全部的工做就都作完了,这就是CI
的魅力。
赶忙试试吧~