最近经常看见关于jenkins 各种文章，大约是anroid/iOS端的共同打包处理。UITest等，其中最为突出的一点就是能够可视化所有的结果。
于是找了几篇详尽描述的博文，开始集成并完成项目的打包工作。
jenkins的安装并不复杂，首先是要安装java环境，然后再安装jenkins 当jenkins安装完成后，会在你的电脑下新增一个jenkens用户，这个用户环境就是干净的。打开jenkins的软件其实是打开本地的一个网页服务器，类似Tomcat搭建本地服务器那种。
接下来就是使用了，为了完成打包的功能，需要创建一个新的工程。
我测试的工程中涉及到的功能有，svn拉取代码，添加pod 的依赖库，build 工程文件，clean工程文件，打包成为.ipa文件，上传到发布平台，邮件通知相关人员，除此之外还有添加单元测试用例等。
然而jenkins本身并没这些功能，jenkins是一个管理整个流程的工具，而需要针对多个平台，比如shell 比如python 比如xcode 比如svn 都需要通过安装插件，用插件来管理这些对应的过程。
我上面讲到的过程 svn拉取代码 需要添加svn的插件 添加pod库的依赖，没有固定的方法，就是在shell脚本中添加 pod install 的命令行， 至于clean build 和packege 过程，均属于xcode的功能，于是需要安装xcode 插件，以及keychian Provisioning Profiles 插件，xcode插件是通过调用本地的xcodebuild 在终端中运行xcode代码，而xcodebuild 需要 证书和配置文件，需要通过 keychian Provisioning Profiles 来导入，这也是整个使用jenkins 最大的坑所在，后续会提到，最后需要安装上传的fir.ic来执行上传到fir的相关插件等。 一个项目所包含的插件大概就是这样。
然后是填写插件里面的内容，
首先是 测试工程名称，保留多少次测试数据，因为每次测试会产生测试结果，我至少经历了50次以上的测试失败，这样就可以保证只留下最后20或30次的测试数据。便于回看错误原因。
然后是添加svn拉取路径，以及svn的账号密码，拉取后执行一段pod 的命令，就到了最关键的xcode内容填写部分了，要填写project文件位置，workspace文件位置，是处于debug 还是release状态。导出ipa的证书类型，导出ipa的文件名，最复杂的部分是要传入login.keychain以及打包用的Provisioning Profiles证书，login.keychian中包含了你本地所有的登录相关的证书文件，用钥匙串打开可以发现所有的证书文件都在里面，而Provisioning Profiles在本地当前用户的
资源库–MobileDevice-Provisioning Profiles文件夹下，但里面有多个配置文件，要判断哪个证书是对应的哪个配置文件，可不是件容易的事情，一般来说就是把所有的配置文件都上传，然后一个一个尝试，编译能通过的证书就是对的。
这里就涉及到了ios证书相关的内容，xcode 编译项目到手机上运行，需要证书和配置文件，才可以运行起来，这个使用的是开发证书，只有包含在开发证书里面，uuid添加到证书里面过的手机设备，才能运行起来项目， 而发送到appstore 供用户下载使用或者企业用户通过二维码扫描下载的app的需要使用发布证书，这个是不受用户的手机uuid的限制的，任何人都能使用，注意企业证书是有最大使用人数限制的，不然所有人都用企业证书了。而下载到本地的证书 是和identifier关联的，每个app 都有一个唯一的identifier 这样就形成了 苹果的开发者账号下 有多个证书，每个证书又有对应的Provisioning Profile 配置文件，只有证书和配置文件以及identify都对的上的时候，项目才能运行到手机上，打包等操作。
可以看出如果不是xcode简化了这个过程，对于证书的配置会变得非常复杂，而jenkins并没有这些权限，这些证书配置文件 所在的文件夹内容必须全部上传到jenkins服务器，然后在xcode插件中选择对应的证书 和配置文件 teamid（这个在证书右键显示简介里面有），就开始尝试项目了。
svn拉取和pod install 的过程都非常顺利，但是build 和package的过程问题百出，
我遇到了以下的问题：
No profiles for ‘com.xxx.demo’ were found: Xcode couldn’t find a provisioning profile matching ‘com.xxx.demo’.
Code signing is required for product type ‘Application’ in SDK ‘iOS 10.3’
这个是xode8 以后 项目都是使用自动签名了，苹果不会把打包的细节放进.project文件夹，当然jenkins也就找不到真实对应的配置文件了，没有别的解决方式，只能将苹果的自动签名关闭，改为手动签名，同时要将schemes文件上传到svn。这个是在xcode的运行按钮旁 点击项目 选择 mange schemes 选择 分享
打钩 ，并且改成workspace ,而有一点要提到的是，一般schemes 是共享schemes的意思，在svn多人管理开发中，这是全局忽略的文件，会非常容易引起冲突而且没必要上传的文件，这里就不得不将忽略移除，并将这里相关的细节上传。jenkisn 终于能够读到相关的内容了。这里千万不要把pod库里面的内容也改成workspace并 分享出去，如果分享出去，会导致pod install 的时候，pod会认为项目中并没有pod 相关的scheme库，而添加新的pod scheme进去，项目中就存在两份pod scheme 文件了。
接下来的问题是：
ld: library not found for -lMasonry clang: error: linker command …
出现这个问题的原因是工程中使用了多project，一般我们会在workspace 下建立多个project 如果要编译项目，就涉及到libaray库路径的问题，pod本身会导入自己到文件位置到 library search head 下，但是多project是，这个路径就是修改过的文件了，pod无法覆盖自己的文件位置到libary search head 下面，如果是用xcode 直接打包，xcode能够找的到对应的位置，但是jenkins 打包 本地文件没有指向，就自然找不到对应的库，因此到build setting 下找到 libaray search head 然后拷贝当前的路径（包含了project的）。然后点击删除，这时候pod 的库就都出来了。然后把之前拷贝的包含project的库路径再添加进去，再看看scheme 文件是不是多个 ，把多余的删除了。再上传到svn ，就不再报这个错误了。这里有一点是这样的。多project工程 libaray 一定是自己维护的。还遇到 了推送证书的问题，因为推送证书是另外一个identify 不是这个，所以会无法通过编译，我先暂时删掉了推送相关的配置文件，为了先把项目运行起来再做处理。
最后是这个问题
* ARCHIVE SUCCEEDED *
Cleaning up previously generated .ipa files Cleaning up previously
generated .dSYM.zip files Packaging IPA
error: exportArchive: No valid ios Distribution signing identities
belonging to team XXX were found.
Error Domain=IDEDistributionErrorDomain Code=1 “No valid iOS
Distribution signing identities belonging to team XXX were
found.” UserInfo={NSLocalizedDescription=No valid iOS Distribution
signing identities belonging to team XXX were found.}
* EXPORT FAILED *
Failed to build
Build step ‘Xcode’ marked build as failure Finished: FAILURE “`
内容表明 ARCHIVE成功 但是EXPORT 失败了，因为没有找到对应teamid的发布证书，
这里明白了是证书问题，应该就是login.keychian的问题，在本地确实是这个证书的情况下，
上传了无数次login.keychain 确每次都卡在这里，询问了各路高人 也都是重新配置keychain 和
配置文件，也说明了这里想配置成功完全是非常难的，因为你不知道会碰到什么问题。也没有相关的
一个合理的解答。
到这里就进行不下去了，也显示出jenkins的弊端，所有的任务都依赖插件，任何一个插件都是项目失败的
风险，这里就是由于苹果的安全机制证书机制等造成的。xcode插件不能很好的适应这些，而把复杂的证书和配置文件管理交给了用户，但在jenkins 赶紧的环境下又拿不到这些相关的数据，被迫将xcode项目改成不方便的手动，不合适的分享机制，自己去改本地的本来不用管的配置项，并上传自己的kechain和配置文件，这样看来，会进一步加大app安全性降低的风险，再考虑到每个项目都需要这么配置一次，如果搭建jenkins 的管理人员不懂xcode以及相关证书的内容，那么完成搭建完全就靠猜测了，跨平台就更难了。除此之外，xcode每年都会更新一次，有很大几率改安全验证和打包机制，如果jenkins 对应的xcode插件没有
变更，就会造成测试代码直接无法跑通，辛苦的构建就没有使用价值了。
于是我转变思路，尝试将我本地的打包python代码，python中包含了xcodebuild 打包的全部流程。这么做的原因是当前用户可以拿到配置文件和证书的管理权限。运行后出现了 这个export formart错误。
查了原因是因为苹果在xcode8.3后改变了 打包规则，export formart 已经废弃，于是更改了python的代码
细节如下，这里就将exportProvisioningProfile改变成了exportOptionsPlist ，并在plist 文件中添加了相关的设置。
#xcode 8.3 以前
# signCmd = 'xcodebuild -exportArchive -archivePath ./build/%s.xcarchive -exportPath %s/%s/%s_%s_%s -exportFormat ipa -exportProvisioningProfile \"%s\"' %(PROJECT_NAME, OUTPUT, VERSION,PROJECT_NAME,VERSION,CONFIGURATION,CONFIGURATIONNAME)
#xcode 8.3
signCmd = 'xcodebuild -exportArchive -archivePath ./build/%s.xcarchive -exportPath %s/%s/%s_%s_%s -exportOptionsPlist ./AutoBuild/plist/%s.plist' %(PROJECT_NAME, OUTPUT, VERSION,PROJECT_NAME,VERSION,CONFIGURATION,PROFILE)这是后再次打包，一次性就通过了，比较一下时间，几乎没花费太多时间。
于是想到不用jenkins 的xcode 插件，调用我自己本地的python文件就好了。
于是我将本地打包的python文件上传到svn ，在从jenkins 把代码拉取下拉，注意svn的路径结尾
要增加一个@HEAD 才能保证代码以svn服务器为准，防止svn和本地时间不同步造成很久都无法
update最新代表的问题。
观察发现可以将运行代码写在shell的脚本中，于是添加到pod 的脚本后面
python ${WORKSPACE}/XXX.py如果不这样写，是无法找到python文件所在的路径的。就会报找不到文件的错误。
这样也不用上传keychain和配置文件。
在我认为没有问题的情况下，jenkisn 报错了。和xcode插件出了一样的问题
Cleaning up previously generated .ipa files Cleaning up previously
generated .dSYM.zip files Packaging IPA
error: exportArchive: No valid ios Distribution signing identities
belonging to team XXX were found.
Error Domain=IDEDistributionErrorDomain Code=1 “No valid iOS
Distribution signing identities belonging to team XXX were
found.” UserInfo={NSLocalizedDescription=No valid iOS Distribution
signing identities belonging to team XXX were found.}
* EXPORT FAILED *
Failed to build
Build step ‘Xcode’ marked build as failure Finished: FAILURE “`
为了验证是不是jenkins 本身的原因 ，我切换当前用户为jenkisn 用户，
找到了jenkins 的测试文件目录，在 共享 jenkins workspace 目录下。 这个目录下的xcode 文件全部都是锁住的，不能修改，
但是python文件是可以在终端下运行，运行 ，打包，又能够非常轻易的打包成功了。证明就是jenkins 本身的问题。
至此 ，我认为还是jenkins的某些配置导致了无法打包成功，于是决定放弃使用jenkins了。
本地的python打包到输出非常简单，然后就是上传ipa包到平台，我开始选择的是蒲公英。
但是蒲公英需要身份验证需要上传身份证等详细信息，因此换用fir，fir支持多次上传，每日
10次的免费下载，无限下载次数需要身份验证。并且支持终端上传，只需要在线上登录fir官网
然后获取token 填入终端，并添加命令就可以实现上传了。
总结：
jenkins适用于项目比较稳定，用户量比较大，需要长期维护的单一项目。才有维护的必要性。
因为jenkins 的项目搭建非常费时，也需要专人的维护，所以建议还是是用本地的脚本处理这些事物。
更加的简单高效。本地脚本的缺点在于可视化，不直观。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
