搭建 iOS 自动打包发布持续集成系统

pkwenda 发布于2019-06-25 15:31 / 3467人阅读

摘要：持续集成系统想必看文章的应该都知道是什么东西，应该都清楚，如果不太明白的，移步总结起来其实也很简单把构建和发布的问题自动化简单化。安装最新版中已经将系统内置了，所以我们只需要部署即可。

概念

原先搭建这套东西其实没多少事，但是受人邀请，还是写篇文章防止后来人踏坑吧。

持续集成系统（CI）想必看文章的应该都知道是什么东西，应该都清楚，如果不太明白的，移步 https://en.wikipedia.org/wiki/Continuous_integration

总结起来其实也很简单：把构建和发布的问题自动化、简单化。

你可以想象这么一个场景：

当你的代码写完后，敲入一个git push，CI 系统自动帮你compile/test/archive/publish 而你只需要坐在那边，喝一杯java就够了。

对于爱“偷懒”的程序员来说，这是十分惬意的事情，因为我们最自豪的就是解放自己的生产力，让自己不要花时间去做一些无意义的事情，既伤神又费力。

安装Gitlab

当然，在当今的时代，我们拥有docker这种神器，其实安装这件事情，也已经很傻瓜化了。

OK，那么简单几行命令搞定

docker pull gitlab/gitlab-ce
docker run -d -P gitlab/gitlab-ce

如果需要进行端口映射，请参考-p参数

当你配置好之后，访问你的母鸡地址，出现这个页面就是部署好了，然后就是注册和登陆的事情。

安装Gitlab CI Runner

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的二进制文件，我们知道要把它做成服务的话，需要以下步骤：

install

start

register就是告诉server 这个runner的存在，install是安装成系统服务，start就是启动服务啦~ 这3个命令很简单。

那么，我们先执行gitlab-ci-multi-runner的run看，它是不安装系统服务，直接跑的命令。

好嘛，一来就发现刺眼的3个warning，对，就是这3个warning把我带入了深渊。它的意思很明确，要求我们用root身份执行这个命令。

但是！！ root是不能在Xcode archive 完之后进行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 和 xctool

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

然后导出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中配置到的那些：





    compileBitcode
    
    method
    ad-hoc

执行完xcodebuild 就得到了我们的ipa文件，如果是手工敲命令的话，就是这么几个步骤。

集成到Gitlab

那么如何让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的魅力。

赶紧试试吧~

云服务器超融合服务器持续集成软件持续集成敏捷持续集成 python持续集成

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/16376.html

fir.im weekly - 「持续集成」实践教程合集

摘要：来这里看看的工程师如何进行持续集成与持续部署。主要介绍了豆瓣移动持续集成和测试相关实践，用工具化自动化社会化测试来解决遇到的问题，将打包发布环节自动化。这期的持续集成实践分享就到这里。我们常看到许多团队和开发者分享他们的持续集成实践经验，本期 fir.im Weekly 收集了 iOS，Android，PHP ，NodeJS 等项目搭建持续集成的实践，以及一些国内外公司的内部持续集成...

A Loity 2019-06-27 13:42 评论0 收藏0
fir.im weekly - 「持续集成」实践教程合集

摘要：来这里看看的工程师如何进行持续集成与持续部署。主要介绍了豆瓣移动持续集成和测试相关实践，用工具化自动化社会化测试来解决遇到的问题，将打包发布环节自动化。这期的持续集成实践分享就到这里。我们常看到许多团队和开发者分享他们的持续集成实践经验，本期 fir.im Weekly 收集了 iOS，Android，PHP ，NodeJS 等项目搭建持续集成的实践，以及一些国内外公司的内部持续集成...

Atom 2019-06-25 15:21 评论0 收藏0
fir.im weekly - 「持续集成」实践教程合集

摘要：来这里看看的工程师如何进行持续集成与持续部署。主要介绍了豆瓣移动持续集成和测试相关实践，用工具化自动化社会化测试来解决遇到的问题，将打包发布环节自动化。这期的持续集成实践分享就到这里。我们常看到许多团队和开发者分享他们的持续集成实践经验，本期 fir.im Weekly 收集了 iOS，Android，PHP ，NodeJS 等项目搭建持续集成的实践，以及一些国内外公司的内部持续集成...

YPHP 2019-06-24 19:27 评论0 收藏0
React native 持续集成实践

摘要：在项目开发中，我们使用搭建了一套持续集成的环境，来自动完成。它可以处理所有繁琐的任务，如生成屏幕截图管理以及发布。对于，会发布到。首先到官网申请帐号并登录，会提示需要到安装插件。运行下面的命令，即可打包并发布到。在React Native项目开发中，我们使用CircleCI + Fastlane搭建了一套持续集成的环境，来自动完成CI CD。基本需求每次push代码，CI可以自...

dreamGong 2019-06-25 11:35 评论0 收藏0
DevOps 基于Walle的小型持续集成实战（一）概述

摘要：该文章用于概述一个小型持续集成环境的搭建的方案什么是持续集成持续集成作为当今软件开发实践，可以简单理解为团队开发相对频繁的集成他们的工作，一般让每个成员每天至少集成一次，而这回造成每天会有多次的版本发布。该文章用于概述一个小型持续集成环境的搭建的方案什么是持续集成？持续集成作为当今软件开发实践，可以简单理解为团队开发相对频繁的集成他们的工作，一般让每个成员每天至少集成一次，而这回...

Yangyang 2019-06-28 17:22 评论0 收藏0