专人处理任务

• 基于release分支建立发版分支（格式：feature_x.x.x）
• 测试通过后合并发版分支代码到release上
• 基于release分支出生产包
• 上架完成后将release分支合并到master分支上，基于master分支建立tag（格式：release_x.x.x）

App开发流程一览

• 创建Task + 需求评审
• 创建发版分支（专人处理）
• 每次提交的代码都必须Review
• 自测通过后提测
• 测试通过后进行安全审核，出安全审核包，并提测
• 基于发版分支出预生产包
• 测试通过报告出来后，合并发版分支到release分支，并出生产包（专人处理）
• 上线前突发问题处理原则（测试主导）
• 通知运营同事添加渠道配置
• 测试回归生产包，通过后送审
• 出Android渠道包 + iOS（TestFlight包和App Store包）（专人处理）
• 上架完成后续动作（专人处理）
• 分发渠道统计

创建Task + 需求评审

• 这个一般由产品来完成，优化任务由开发自行创建
• 创建Task，设置标题、优先级、详情（详情中可以描述本次task背景，技术方案，接口地址等等 ）、订阅者（选择关心这件事的人）
• 创建成功后，会产生Task编号，根据Task编号创建开发分支

创建分支

• 各小组分别基于master分支上创建发版分支，格式：feature_x.x.x（专人处理），正常情况下其他人不要创建此分支
• 发版分支创建完毕后，具体开发任务从此分支进行迁出，按任务编号创建独立分支进行开发，格式为：feature_x.x.x_Ttask编号，如：feature_1.0.0_T123456

每次提交的代码都必须Review

• 做好代码提交切割，尽量避免一次提交太多代码
• 代码Review没有问题后在Task下面备注（由代码Review的同事填写）

自测通过后提测

• 自测（自己测试 + 过完测试用例）
• 提测前进行内部提测演示
• 自测通过后，经过发版功能确认后，将代码合并到发版分支上
• 如果master有代码更新需要主动合并到发版分支上来（比如：修复线上bug等）
• 切忌不要将发版分支的代码合并到开发分支上，以保证开发分支的单一性
• 在发版分支上修改完bug后，cherry-pick到开发分支上
• 提测后自测出bug需要通知测试同事协助建立bug任务，写清楚测试范围

测试通过后进行安全审核，出安全审核包，并提测

• 出安全环境的App包，将App包上传到应用安全评测平台进行扫描（如果公司有这一步要求的话）
• 在安全提测Task上补充提测信息，格式如下：（~~~ xxxxx ~~~表示要替换的内容）

iOS/Android安全环境安装包
~~~ 此处上传安装包 ~~~
【安装包MD5值】
【安全评测平台扫描结果链接】~~~ 扫描结果链接 ~~~
【代码分支名】~~~ feature_x.x.x ~~~
【代码仓库地址】~~~ 代码仓库git地址 ~~~

• 通知测试同事可以进行安全审核了，安全同事审核通过后备注task

基于发版分支出预生产包

测试通过报告出来后，合并发版分支到release分支，并出生产包（专人处理）

• 测试通过报告发出后，此时就进入封版阶段
• 合并发版分支代码到release分支（在合并到release之前，一定要确认release上没有未上线的代码 ），基于release分支出生产包
• 由开发基于release出生产包
  • iOS：出TestFlight包（对指定用户进行推送）、App Store包进行送审
  • Android：将App包进行加固并签名（官网包、各大应用市场的渠道包交给运营同事）

上线前突发问题处理原则（测试主导）

• 上线前功能调整 或者 bug修改由测试决定是否进行修改，测试同意后才能修改

通知运营同事添加渠道配置

• iOS/Android添加各渠道的配置

测试回归生产包，通过后送审

• 验收下功能是否正常，如无问题即可进行送审

上架完成后续动作（专人处理）

• 将release分支代码合并到基于master分支，基于打版本tag，格式为：release_x.x.x
• 标签一旦打上之后，不得修改、重命名、删除
• 标签如需修改，应再打一个新标签，名称后面加上数字后缀，格式为：release_x.x.x_n

分发渠道统计

• iOS

• Andriod