gitflow 与 fastlane 以及自动化的思考

gitflow是团队协作中常用的工作流指南.

我们在工作中按照gitflow的工作流来进行分支管理的话, 整个开发流程会非常清楚.

下面一个图是非常常见的gitflow的工作流.

比较建议的是远端管理 master 和 develop 两个分支, master 存储正式发布的历史, 而develop分支作为功能的集成分支.

gitflow.png

正常发布新版本的流程

1. git flow start release 1.0.1, 从 develop -> release 分支
2. 需要做常规的版本相关的操作:
   • 修改version相关内容: 代码中的version, 工程编译中的build version, podspec version, 资源中的version
3. commit to release
4. test: 主要是fastlane
5. git flow finish release 1.0.1, 从 release -> master 合并, 并打tag, 并且合并到develop中.
6. update develop中的状态

其中第4步, fastlane的主要工作如下:

1. fastlane 生成WBSDK
2. 包装WBSDK -> SDK对外发布zip + 测试使用ipa(主要是cp, 然后文件夹和文件操作)

实例:

fastlane打包以后的结果是:

WBSDK/ios/WBSDK.framework
                |-- Headers
                |-- Resources
                |-- WBSDK

最后包装以后的分成两块:

// 直接给合作方可以集成的SDK的文件夹目录结构
WBSDK_F/
    |-- Frameworks/
    |-- Resources/
    |-- WBSDK_F.podspec 

WBSDK_Test/
    |-- WBSDK_F/ //刚刚整理好的文件夹
    |-- podfile  //内部引用 WBSDK_F.podspec
    ...

需要编译并签名WBSDK_Test.ipa

旧版本打包的流程

默认在develop分支.

1. 切换分支到master
2. 直接复用上面的第4步过程. 打包并包装SDK + test.ipa