iOS开发流程思考

开发版版，内部版本，产线版本滚动前进

背景介绍

在6月25日由InfoQ主办的GMTC（全球移动技术大会）上，链家网的郭晓铭分享的内容是《万亿O2O移动平台的敏捷之术》。没机会去现场，从下载的PPT看，大体上还不错，做法也算合理，有一定的借鉴之处。下面这张流程图就是PPT中的内容。

工作流程.png

• 图画的不错，蛮清晰的

• 能够运转2周一次的Sprint，也相当不错

• 需求领先一个周期，后端领先一个周期，中间层和UI再领先一个周期，发布推迟一个周期，基本上也是可行的。

• 如果是严格按照时间滚动进行，未完成的移到下个周期实现，那么就更好了。

• 需求和后端准备好，然后客户端再跟进，维护一个版本，符合一般大众的思路。总体上来说，还是不错的。

• 比较理想化，是大多数人希望达到的状态。

问题点

• PM需求出来之后，关注的是后端实现，这个PM是后端的PM还是移动端的PM？如果是指一个人，要求这个PM从后端到移动端都熟悉，是否太理想化了？如果是指好几个人，相互之间的配合能够表现得像一个人这么顺畅？

• 从后台到前端，这么长的链路，能配合良好吗？

• 如果有需求变更，这么长的链路，能协调一致吗？相关方这么多，能达成共识吗？

调整观点

写公司的网络库，在配置一块，可以看到url分为“Production”、“UAT”、“Test”三种模式。从这里得到启发，就分为开发版版，内部版本，产线版本三种，三条生产线。

开发版本

• 移动端PM + UI + 移动端RD + 中间层API + QA 组成一个虚拟团队

• 面向终端用户，进行需求收集、产品设计、编码实现

• 没有任何依赖，（只要后台能实现就行，不需要等后台进度，数据由QA想办法造），有条件实现2周一个Sprint

• 按照2周一次的频率发版本，遇到完不成的功能，就延迟到下一个Sprint实现。QA测试完，能够满足功能就好了。

• 开发版本都不对外发布，测试通过的作为内部版本候选者

• 有条件的可以做自动构建，自动化测试等

内部版本

• 后台PM + 后端RD + 中间层API（部分工作）+ QA 组成一个虚拟团队

• 参考已经完成的开发版本，进行后台实现，并对接真正的数据接口

• 时间周期可以按照后台的实现节奏。一般2周一次有点过于频繁，可以考虑1个月一次。

• 可以根据实际情况，从众多的开发版本中选择一个合适版本，进行对接。

• 进行内部发布，内部试用。如果发现bug，另外拉分支进行bugfix。只要同步到主干以及被选中的开发版本即可，其他的版本没必要去动。

• 可以采用企业账号，自由度大，但是要多花钱；也可以用TestFlight，免费，但是有100人的限制，而且还要登记手机的UUID

• 内部试用一段时间，感觉满意之后，作为发布版本候选者。

发布版本

• 有PM和运营团队负责

• 选择合适的，通过内部验证的内部版本候选者作为发布版本

• 灰度发布，10%，30%，30%，30%，逐步放开流量

• 时间可以选择一个月，每周进行一次扩容

• 如果遇到bug，可以选择降级，可以额外拉分支进行hotfix

• 发布版本从内部版本中选，但是并不是每一个内部版本都要发布；具体情况由PM和运营团队灵活掌握。

优势

• 开发，内部试用，正式发布三者隔离，并且由不同团队负责，从流程和人员上实现了解耦

• 将很长的一个流程分为两个独立的自循环，降低了整体间的依赖

• 开发版本，内部版本，正式版本形成一个类似金字塔的结构

• 结合测试、内部试用，灰度发布，保证了产品质量，并且风险可控

• 从原先的后台功能推动，变成用户的需求拉动，更贴近市场和用户，更容易创造出用户爱用的产品