前言
上个月，我们B612跨国团队协作出现因为发bug-fix版本，导致我们iOS版的一个SDK版本集成了开发中的代码的事故，我们收到错误警告后，立即停止App更新，立即关闭SDK的访问入口，修复版本后通过加急审核的方式，第二天立即发版本成功修复该bug。虽然事故响应处理的及时，经过这些天后，最终还是影响了数千问题版本未升级的用户不能访问该SDK功能。
为此我们团队梳理了跨国团队的版本开发发布流程管理规范，以适应多业务线多团队协作的情况，并为各个业务线提供更准确的开发发版的规范性指导。
我把一些敏感的信息给替换掉，以让本规范适合一般的跨国跨团队的协作规范，方便读者参考。
背景
B612团队是跨国协作的，团队主要由中日韩三国成员组成，其中以中韩团队为主。中方负责新业务线的开拓，也负责多个SDK的开发工作，韩国负责主app的研发维护，同时版本发布权限在韩国。中国这边项目都是以SDK的方式集成在主app当中，B612通过gitsubmoule引入中国团队的各个SDK，然后通过路由SDK去调用各个组件服务。
仓库关系图
协作流程
1.流程图
2.流程描述
- 版本需求评审会议，两方产品需要邮件确认中方SDK版本和对应的B612 App版本，并在需求文档中明确。以某SDK团队举例，SDK v4.0.0 ->B612 v9.1.10。如果版本对应关系未确定，开发基于先前稳定版分支进行需求开发。
在wiki上维护版本迭代完成日期，QA完成日期，上线日期信息。双方产品需及时同步版本变更情况，共同维护该WIKI，保持同步更新，开发人员及时关注。可参考： https://wiki.navercorp.com/display/LFS/B612.SNOW.Release
中国项目团队进行正常版本的开发和测试验证。
- 在QA进入回归的重要时间点，双方通常不应再有版本调整，进行正常的回归。但如回归前后有版本调整变化，双方产品及时同步，并周知到开发测试调整版本对应关系代码后再回归。
- 双方Beta 版本QA signOff后，双方需邮件通知对方团队signoff，中方开发确认最终B612代码集成中方SDK项目代码版本正常，由韩方打包发布到testflight进行线上回归。如中方团队确认中发现集成异常及时与韩方沟通反馈，修改版本后，再通知韩国可以打testflight包。
- 中韩团队对testFlight包验证，如未发现异常，可以正常发布版本。如发现异常则处理异常，补充testFlight包再发新包。
#开发流程图
开发合并管理流程图
开发流程描述
- 新版本需求评审时，初定app版本与中方团队版本对应关系。如以潮拍为例，B612 9.1.10 对应SDK4.0.0。如果版本对应关系未确定，开发基于先前稳定版分支进行需求开发。
- 中方开发基于B612 App当前最新版本分支(如：version_cn/9.1.10)新建开发测试使用分支(如：feature /kaji_9.1.10_cp_4.0.0)。
- 在SDK仓库的develop分支开发需求，实现需求功能。
- 提测之前将韩国主分支version_cn/9.1.10最新代码合并到feature_cn_beta /kaji_9.1.10，基于feature /kaji_9.1.10_cp_4.0.0分支使用jenkins打包提测。
- QA回归SignOff完成，合并develop分支代码到master分支，并打版本tag，如4.0.0。
- 修改feature /kaji_9.1.10_cp_4.0.0分支的cartfile文件集成SDK版本（如4.0.0）。通过GitHub走PR合并流程合并进B612分支version_cn/9.1.10，同步韩国同事review合并。
- 韩国回归完成后，韩国通知我方开发技术确认QA Sign off，我方团队确认无异常，韩国团队正常发布版本到testflight,再通知到我方团队验收确认，确认正常，由韩国团队发布版本上线。
SDK 的Git仓库管理
分支介绍
- develop分支（开发主分支）：开发需求过程中代码合并到该分支。
- master分支（版本主分支）：线上稳定版本分支，管理线上所有稳定版本代码、管理每个版本的tag。
分支管理
- 需求开发过程中，开发成员更新代码到develop分支，开发成员从该分支同步最新代码。
- sign off 后合并develop分支代码到master分支
- 在master分支打版本tag。如4.0.0版本，打tag：4.0.0。
- hotfix过程，需基于master分支（或者基于tag）创建hotfix分支。如修复4.0.0版本的bug，创建分支hotFix_4.0.0。
