实施目的：优化开发-测试-发布流程
当前情况：iOS端开发后手动Build给QA，期间QA提出bug，开发修复后再次进行手动Biuld， 且发布后，无法保证发布版本与测试版本的同步性。故提出此方案，旨在优化流程。
第一阶段优化期望：iOS自动Build至蒲公英内测平台，同时生成生产环境IPA至TestFlight，二者构建版本号相同。经QA同学在蒲公英平台下载验证测试环境通过后，通过TestFlight App验证正式环境，通过后直接由运营同学上线。
第二阶段优化期望：测试IPA，正式IPA统一由云端管理。验证后，由fastlane发布至App Store Connect。
为什么是两个阶段？
- 目前开发，QA人员、精（zhi）力（you）均（wo）有（zi）限（ji）。
- 蒲公英平台为付费专业版，理论上没有流量限制，功能丰富（密码提取、微信通知、浏览器下载安装不需要使用ITunes同步），运营同学可以在App Store Connect直接提取QA验证过的IPA进行操作，既节省了额外学习Application loader时间，也避免了微信、钉钉等传输工具所带来的风险。（转发出错，IPA被破解、注入）
选型思路
在调研了一些自动化工具后，选择了fastlane + jenkins， 二者均可以单独使用，也可以搭配使用。
fastlane优点在于轻量化且配置容易，上手快，它提供了许多好用的工具，还有直观的脚本，让你可以不用碰触到很多系統的细节面，也能够做到各种客制流程，而且它同時支援 iOS/ MacOS 和 Android 平台。大多数的设定你都可以透过commandline 直接跟 xcode 互动做到。
jenkins是一個有网页 UI 的自动化工具，让你可以利用 GUI 设定工作內容，像是设定 project 参数等，也可以做到执行排程，像是每日定時任务等。功能强大，支持git，以及历史版本的保存（协同云端）。QA可以自由在分支间，版本间进行切换。
解决思路
使用fastlane作为过渡工具，建立起新的标准流程，待后期条件成熟，将jenkins加入。二者的组合可以最大限度发挥fastlane的构建速度与jenkins版本控制的优点。
为什么不直接是jenkins？
- 在日常的使用中，jenkins凭借其插件的庞大数量和丰富的功能让人心旷神怡，但也正因如此，在和xcode的配合中，由于每个插件的维护和更新时间无法控制，因此会造成版本过渡期的失效。问题出现场景：适配xcode 10 SDK，更新后插件扔停留在xcode 9，此时自动化功能受损。抛开插件，jenkins不具备直接上传的能力，这就意味着不论是正式IPA、测试IPA，都将直接暴露于各个非专业传输工具中，相关工作人员的桌面、废纸篓中。风险不言而喻。
- 为发挥jenkins的最大效能，云端功能和本地的一些参数需要时间配置并进行测试。
第一阶段相关技术细节
xcode方面
在编译器中，首先通过Preprocessing + Configuration加入新的环境及配置项，将API、包名（bundle name、bundle name + Beta）区分开。
fastlane方面
为了节省阅读者时间，关于fastlane的安装和配置文中不在赘述。 当在控制台执行测试工作流时，会自动生成一个生产环境的IPA提交至App Store Connect。
注：截止本稿发出，第一阶段已准备完毕。
第二阶段相关技术细节
为了节省读者时间，关于jenkins的安装和配置文中不在赘述。
- 构建触发器，这里我们选择Poll SCM，然后在下方输入框填入日程描述
H/10 * * * *，表示每10分钟从仓库拉取一次，如果有新的提交，那么构建项目。 - 写入shell文件，此处填入在之前控制台执行的fastlane命令。
更深层次的功能会在使用测试后逐渐完善。
