Cocoa平台的工具链
从最开始的原始播种工具与刀耕火种的开垦方式，到现代化的机械农机和水库水坝构建灌溉系统，随着工具的演化和基础设施的发展，农业才能支持人类人口爆炸式的增长。
挑战在于工具和基础设施的积累、通用性。
日本从明朝引进磨盘，改变了面食不能加工的面貌。Ruby语言秉承Prel语言的精神，诞生了与CPAN(Prel拥有庞大的难以想象的第三方库代码，CPAN则是较早处理语言内部代码引用和依赖的包管理器)精髓一致的RubyGem，无数受到Unix文化熏陶的程序员方便的将以前的社区积累的代码库与工具集转移到让他们感觉舒适的Ruby社区，Ruby社区借助工具和基础设施转移的优势，Ruby on rails迅速成为最火热的Web技术栈。在以前，Cocoa平台的开发者像是最初使用Mac的小众人群，随着移动互联网时代的浪潮来临，无数开发者开始关注并成为Cocoa平台的开发者，甚至有大量的开发者的职业生涯的第一个开发平台就是Cocoa，当然这个平台上的优秀开发者总是拥有其他平台优秀的开发经验。
什么是工具链
什么叫做工具链，编写程序需要使用编程语言，但是只有编程语言是不能产出实际的程序或应用的。写出了文本代码得经过编译、链接、加壳封装成可执行的文件最终发布才能够运行在设备上，开发环节同样重要，开发的时候debug得需要调试器，语法要提示还有高亮，语法分析器和静态分析器提供代码扫描和分析的支持，引用系统框架或者是第三方库、项目复杂以后管理庞大数量的代码，也需要使用库管理工具或者是依赖管理工具去解决。移动软件分发平台一般都是应用商店模式，如果需要商业发布，发布也需要发布工具来完成安全和便捷的发布流程。到此，前面提到的，编译器、链接工具、调试器、静态分析器、包管理工具和发布工具等等算作是一门开发语言或者某一开发平台的工具链，像是一根链条从开发、测试、发布一整套流程下来需要参与的工具集。可有人问，为啥我没听说过呢？那是因为你使用了Visual Studio或者是Xcode等等这样的IDE，IDE其实已经把这些工具标准化组织成一套完整的开发环境给开发者，这是商业开发平台的好处，程序员不需要关心这些工具问题，但是对于开源界，你也总会听说过诸如GNU工具链、Ruby on rails工具集等等，Unix巫师使用vim或者emacs开发，用GCC编译，用GDB调试，使用makefile来管理链接等等，让你觉得这一切都好流弊，本篇文章就粗略的介绍一下Cocoa平台下的工具链。
展望Cocoa
随着苹果引导了移动互联网时代，Cocoa平台的新鲜血液越来越充足，可这就像是一片贫瘠的土地，亟待开垦，有经验的开发者一边逐步体味到iOS、MacOS这类类Unix系统的精髓，并深感由C类语言演化的Objective-C和与GCC一脉相承的Clang、LLVM的伟大，但同时也渐渐发现，落后的代码管理机制与C语言也一样饱受诟病(静态库组织代码与缺乏命名空间)，开发者数目庞大却缺乏成熟代码管理工具与库管理平台，使用静态库与通过submodules来组织代码效果也不甚理想，并不能解放开发者手动检查依赖关系，相比于Java社区Ant、Maven、Gradle的发展，Ruby on rails的RubyGem，哪怕是JavaScript的Npm与webpack等等，Cocoa的开发者工具甚至原始的有一些过分，Android开发社区借助Java的力量，以intellij商业开发工具为基础，发展出以Gradle、Android Studio等开发工具集，使得Java开发者能够迅速的投入移动应用的开发。相比之下，Cocoa平台的开发者在面临大规模开发时也逐渐暴露许多工程问题。“中国的造纸术传入西方，给欧洲大陆带来了文明，从此才有了文艺复兴”。在这样的情况下，在第一批转入Cocoa移动开发社区的开发者中，有一大部分来自Ruby社区的开发者，其中Eloy Durán在2011年8月12日创建了CocoaPods，从而揭开第三方开源社区构建Cocoa平台下工具集的序曲，CocoaPods已经成为Cocoa平台下，第三方库管理以及代码管理的事实标准，随着Swift社区建立以及开源，这些已有的工具集又快速的迁移到新的社区，使得Swift的社区在短时间内变得非常活跃且富有生机，随着Swift Package Manager的发布，至少属于Apple的Swift开发团队开始注重这方面的问题，一切都在向好的方向发展。
其实本篇文章是瞎扯淡
为什么这么说，因为Xcode已经提供了从编译链接到发布的一切工具，既然能用为什么还要讲这些，不是在表演技术么？还真不是，Xcode虽然好用，但是有如下几个小问题，第一是没有很好地依赖管理工具，第二是构建工具太复杂，第三是没有比较好的发布工具，只有IDE的发布功能，最后并不能很好的打通这些工具。这有什么影响呢？如果你一直在Xcode下工作，所有的工作需求都是可以通过手动操作被满足的，但是项目规模一上来，诸多的第三方库的管理、不停地构建和打包分发给测试、发布到Appstore的时候总是出现这样或者那样的问题，你需要进行持续集成，但总是受制于Xcode。
思考如下问题：
- 如何避免反复手动给测试打包
- 如何避免反复手动给测试机安装测试版本App
- 当出现大规模并行开发的时候，如何灵活构建多种版本，配置多种构建环境，方面测试能够进行线上常规测试、灰度发布测试、特性分支功能版本测试、bug修复版本测试等等
- 当出现多个版本的时候，如何对接bug跟踪系统
- 团队开发人员数量爆发，引入组件化方案后，主工程如何管理各个发开团队负责的功能模块
- 如何做到代码版本控制工具->代码审查合并->触发构建触发器->配置构建环境->构建打包->分发测试
- 如何构建私有代码共享仓库
Cocoa平台下的工具链
在工作中，个人觉得Cocoa平台比较缺乏完整的商业工具链，但借助Ruby on rails社区的力量发展了一大批开源项目丰富了Cocoa平台的工具链，至少包含如下几项：
- Xcodebuild
- oclint
- sonar
- bundle
- fastlane
- CocoaPods
- carthage
- shenzhen
xcodebuild
Xcodebuild属于构建工具，是Xcode构建功能的命令行版本，官方的 Man-page
该命令行工具可以通过project文件或者是workspace文件，指定target、scheme、buildconfiguration等等来进行编译，同时可以指定编译后的文件输出路径等等，作为基础的命令行工具，可以不适用Xcode工具进行编译打包等等，xcrun又可以提供Xcode一系列完整的工具链调用，在实际开发过程中，有以下几种使用情况：
- 编译完整应用的项目，进行命令行构建与打包，成为持续集成的基础工具，当然也要求CI服务器必须是MacOS环境
- 如果代码使用动态库或者静态库管理和组织，团队内部有这样的共享代码需求或者你从事的是SDK开发，可使用该工具进行动态配置，比如使用scheme与build configuration编译，同一套代码可编译出不同配置的代码库
- 编译资源bundle工程，如果项目内部的资源使用bundle进行组织的，则使用该工具可以灵活控制资源bundle的产出，并与其他工具交互，分发给不同的开发人员或项目
CocoaPods与Carthage依赖管理工具
Carthage
准确的来说， CocoaPods 与 Carthage 并不是完全同一类型的工具，CocoaPods涉及到第三方库的管理、发布甚至带有构建中心代码仓库的功能，相比之下Carthage简简单单是第三方库引用管理的工具，远远没有CocoaPods强大，但其去中心化与不破坏工程结构的做法，使得应付小型项目得心应手。Podfile用以申明项目代码相关性，Cocoapods用来处理各库之间的依赖关系，可以自动下载配置好所需要的库，即便是在管理自己书写的代码的相关系上，Cocoapods也是最好的选择，使用CocoaPods有如下情况：
- 管理工程中的第三方库
- 管理团队开发代码的相关性
- 将书写的代码复用，采取制作成Pod库的形式，引用其他模块的代码也是Pod库，这样可以通过Podfile管理内部代码依赖关系，从而避免库冲突等等复杂问题
- 构建组织内部的代码仓库，用作组织内部代码发布、测试与共享管理
- 每个团队都把自己负责的模块代码以Pod形式提供，模块内代码发生变化，则必须通过更新版本号发布新版本，主工程可以方面测试，一旦出现严重问题则可以回退到之前稳定的版本，从而保证主工程的可壮性
oclint静态分析工具
oclint是一个开源的静态分析工具，在MacOS中基于Clang进行C、C++、Objective-C的静态分析，目的在于可以发现代码隐藏的问题和提高代码质量，如果公司没有codeReview的习惯的话，经常使用静态分析可以稍微弥补一下，大体上oclint可以做到如下：
- 扫描隐形bug，诸如if else逻辑没有完整，异常没有处理等语句的分析
- 扫描没有使用过的代码，包含未使用的变量和参数
- 扫描不符合设置的语法风格，比如方法命名规范与代码包装逻辑规范等等
- 扫描复杂逻辑代码，检查是否有逻辑重叠或者检查循环调用等
在Cocoa平台下，组织持续集成，实施持续交付的过程中，通过每次代码提交入库的时候，进行静态分析扫描，可以将质量问题在交付测试之前就及时发现，开发者可以使用这些工具提前将bug扼杀在摇篮中。比如，在每次git代码提交入库，从分支完成以后可以使用oclint进行静态分析，生成html的代码报告，可以设置质量阈值来根据分析结果是否将提交回滚，重新打回开发阶段。
shenzhen与fastlane构建工具
shenzhen是一个使用Xcode API的命令行构建工具，fastlane则是一套兼容Android与iOS移动端的持续集成工具集，相比于shenzhen，构建工具只是fastlane中一个非常小的子集。fastlane有如下几个套件：
- scan插件，用以运行单元测试代码，在构建之前通过单元测试再开始进行构建，这对于模块代码的稳定性至关重要，也许一些开发者会比较喜欢Mock测试，但面对UI测试和逻辑单元测试，使用UITest与XCTestCase则会更加有效，scan则可以与这些测试框架进行交互，并生成测试报告
- pilot插件，用以绑定测试分发服务，比如iOS构建的版本可以通过它推送到testFlight，测试设备就可以自动获得测试版本
- gym插件，用以替代shenzhen，可以构建打包应用
- deliver插件，可以用以发布应用到AppStore
- 还有诸如cert管理证书和配置文件，snapshot管理上传到AppStore的截图，pem管理推送配置文件，produce通过命令行与iTunes Connect进行交互，match用以管理和同步配置文件和证书
fastlane这样的构建工具已经比较完整的覆盖了Cocoa平台下有关移动开发的工具范围
SonarQube
SonarQube是一个代码质量管理的开源平台，可用于搭建代码质量管理服务器，通过在服务器上构建应用，运行代码静态分析侦测代码质量、运行单元测试进行全面的回归测试、搜索重复代码、评估单元测试覆盖率、通过设置代码规范检测代码风格、检索注释评估代码阅读性、发现潜在的bug生成评估报告。
其实该平台本身不属于Cocoa平台下的特有工具，但一般来说，Cocoa工具链中包含的构建、测试和代码分析工具组合起来就是简单的代码质量管理，sonar是一个质量管理平台，可以在服务器上搭建，可以利用这些工具在管理平台上专门针对Cocoa项目的进行代码评估与质量管理，方便从质量控制这一维度管理项目。
目标
事实上，上述工具的介绍都隐隐约约指向一个目标—持续交付，也许在项目复杂度还较低的情况下，过早的引入软件工程开发的方法论还为时尚早，但开发者应该预见未来项目的规模增长趋势，根据业务需求增长水平，适时引入敏捷开发或者是Devops这样的开发模式或者方法论，工具是开发流程实施的基础设施，回答最初那几个开发实际过程中出现的问题，基础的工具可以实现持续交付，提高开发、测试、运维与QA等部门之间的合作效率，使得出现的诸如交付测试、代码质量管理、发布流程自动化等等得以实现，从而高效的完成工作
fastlane存在的问题
1.出现编码不匹配的问题
[!] incompatible character encodings: US-ASCII and UTF-8 (Encoding::CompatibilityError)
解决方法：
首先在shell中查看环境变量
$ env | grep -e 'LANG'查看是否有LANG环境变量值是否为utf8，如果没有或者不是，则在~/.bash_profile中加入如下内容：
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
最后在$ source ~/.bash_profile重新启动文件夹
2.使用CocoaPods管理第三方依赖以后，增加build configuration出现
clang: error: linker command failed with exit code 1 (use -v to see invocation)
查看编译出错的报告往往是找不到pod编译后的库，因为新增加了一个build configuration以后，编译后的路径就发生改变，这时候，你可以把Podfile文件的所有第三方库引用都注释掉，执行pod install然后再把注释取消，继续pod install
