码迷,mamicode.com
首页 > 其他好文 > 详细

CocoaPods最佳实践探讨

时间:2015-01-29 20:54:05      阅读:258      评论:0      收藏:0      [点我收藏+]

标签:

近期在项目中首次使用了CocoaPods。从软件工程的角度来看,我对目前常见的CocoaPods使用方法有些意见,建议做一些改进。先说一下我建议的最佳实践,后面再分析为什么要这样做。并且希望大家根据自己公司的情况,讨论一下这几项建议是否合理,一起搞出一份真正的“最佳实践”。
 
CocoaPods的常见使用方法参见唐巧的文章《用CocoaPods做iOS程序的依赖管理》。在他的基础上,我提出几条补充。
 
1. CocoaPods生成的Pods目录*不*加入.gitignore,也就是说,第三方库的源码或binary要和产品代码一起,提交到公司内部的版本控制系统上。每次修改Podfile并执行pod update后,把Podfile、Podfile.lock、Pods目录下的改动一并签入。
2. 保证在任何时候只签出一次代码就能直接编译执行,不需要执行pod命令,甚至可以不装CocoaPods就能参与开发。
3. Podfile里所有的库使用精确版本号,不使用任何’~> 1.0‘, ‘>= 1.0‘之类的版本号语法,只使用精确的版本号如‘1.3.2‘。
4. 在项目开发过程中,可以每隔一段时间使用pod outdated命令手动检查各第三方库是否有更新。如果发现某个库有新版本,去第三方库主页查看更新记录,并对版本变动做评估。如果确认有必要更新到最新版本,则修改Podfile里的版本号到最新版本,执行pod update。
5. 如果两个人同时修改了Podfile,第二个人git pull后发现有conflict,resolve顺序是:不动其他文件,先手动resolve Podfile的冲突;然后执行pod update;如果仍有冲突,可以用git reset把Podfile.lock和Pods目录恢复原状,再次执行pod update。此时应该没有pod相关的冲突了。
 
------------------------------------
 
以下分析常见CocoaPods用法的问题,首先看CocoaPods官网上的示例Podfile。
 
source ‘https://github.com/CocoaPods/Specs.git‘
pod ‘AFNetworking‘, ‘~> 1.0‘
 
这两行的含义是,使用github上的pods spec,安装AFNetworking 1.x系列最新的那个版本;如果AFNetworking还依赖于其他库,自动安装合适的版本。
 
假设现在我们的项目中要用到第三方库XYZ,开发流程大致如下:
1. 项目创建者张三在自己机器上安装好CocoaPods。
2. 张三执行pod init,在Podfile里添加代码 pod ‘XYZ‘, ‘~> 1.0‘。执行pod install,把Podfile和Podfile.lock签入代码管理,Pods目录添加到.gitignore。
3. 项目开发人员李四安装好CocoaPods。
4. 李四签出代码,编译,发现pod报错。于是执行pod install后,重新编译通过。
 
这样的CocoaPods使用方法可能引发很多异常情况。考虑第一类场景:
1. Github突然被盾了(曾经发生过)、或公司的外网出口挂了,李四无法成功执行pod install,因此只能眼巴巴的看着项目代码,无法编译。此时张三说,把我本地的Pods目录都拷给你一份吧,虽然这样拷来拷去容易出错,但暂时先这样临时解决吧。
2. Github突然被盾了,公司的持续集成服务器上无法执行pod install,也没法给服务器拷一份Pods目录。于是连续多天无法用持续集成。
3. XYZ开发者在修改代码时,从git上删除了最新版本的tag,并重新加tag到另一次commit上。于是张三和李四得到的XYZ代码是不同的。(虽然AFNetworking开发者很有经验,不太可能出这种错,但其他小的第三方库就不一定了。)
4. 五年后,早就没人使用古老的iOS 7了。XYZ开发者认为该库是针对iOS 7的,技术已经太陈旧,于是从Github上删除了该项目。(还好我们三年前就不再用这个库了。)但某一天公司有个新项目,想参考以前的代码。当打开代码执行pod install时,发现Github上已经没有XYZ库了。
 
以上情况可以归结为:你的代码是否可用严重依赖于别人。你从公司的版本控制系统上获取的代码不能直接编译,还依赖于世界各地很多其他人是否正确配置了他们的代码,还依赖于Github等git服务商是否可用,等等。在极端情况下,会有灾难性后果。
 
再看第二类场景:
5. 在我们项目的开发过程中,XYZ最新版本是1.4。一年后,我们重新打开旧的项目代码,执行pod install,获取到XYZ 1.x系列的最新版本1.7版。在XYZ 1.4到1.7版本之间,改变了一些接口和实现,我们的项目代码很有可能无法编译,或无法正确执行。
 
这里的问题是:常见的版本号写法‘~> 1.0’会在pod install或pod update时检查版本更新,随时将第三方库升级到1.x系列的最新版本。对正在开发的项目来说,经常升级第三方库是可以的。但对已经发布的产品代码,这个变动是不可接受的。已发布的版本必须要有一份固定不变的代码,否则配置管理就失去了意义。
 
还有第三类场景:
6. 张三的CocoaPods安装的很早,和李四机器上的不是同一版本。这两个版本的CocoaPods对依赖规则的resolve算法不同,因此李四pod install失败,无法下载到和张三相同的第三方库代码。这是真事,两周前我们刚刚遇到了,后来解决方法是所有人都强制安装某个旧版本的CocoaPods。
 
这里的问题是:CocoaPods作为开发工具链中重要的一环,它的质量是否有保证?CocoaPods不是苹果官方的工具,也不是像git那样由极富经验的人组织设计开发,我们能否信任它的版本兼容性?具体来说,即不管用什么版本的CocoaPods,pod install后得到基本相同的第三方库。我们看到最近已经出了一个bug,如果时间再长点,三年后的CocoaPods会不会跟今天有较大差异?
对这个问题的一个解决方法是要求所有项目成员安装相同版本的CocoaPods,甚至安装相同版本的Ruby。但一个人需要同时参与多个项目的怎么办?问题的根源还是没变。
 
------------------------------------
 
基于以上分析,我提议的“最佳实践”解决了以下问题。
* Pods目录签入到版本控制系统,使产品代码没有外部依赖,不管什么时候都能从公司内网获取一份可直接运行的代码。
* 已发布版本的产品代码永久固定,不会随时间而变化,方便追踪问题和存档。
* 不要求项目成员装同样版本的CocoaPods,甚至可以不装CocoaPods。降低测试、设计人员使用代码的难度,也避免了CocoaPods本身兼容性引起的问题。
 
转自:http://www.weibo.com/p/1001603800875490492754

CocoaPods最佳实践探讨

标签:

原文地址:http://www.cnblogs.com/dokaygang128/p/4260693.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!