由苹果的4种版本想到的

根据渠道（企业和苹果市场）和模式（Debug和Release）两个维度组合，可以有4种不同的版本组合。

1. `AppStore`渠道`Debug`模式

这是最常用的模式，一般就是所谓的开发版
用开发证书
测试手机的UUID需要上传苹果网站
可以用XCode连接测试机调试，设置断点等
可以用iTools等工具在测试机上安装
没有注册UUID的手机不能用

2. `AppStore`渠道`Release`模式

这是通常所说的产线版本
用发布证书
不能用XCode调试，不能设置断点
不过可以通过XCode安装。运行时会闪出来
不能用iTools等工具在手机上安装
只能从AppStore下载安装

3. 企业渠道`Debug`模式

299美元/年的账号
用开发证书
测试手机的UUID需要上传苹果网站
可以用XCode连接测试机调试，设置断点等
可以用iTools等工具在测试机上安装
没有注册UUID的手机不能用
是企业版的“开发版”
与普通的开发版bundle id不一样，相当于不同的应用。
这个模式也是给开发人员用的

4. 企业渠道`Release`模式

这是通常所说的“企业版”、“内测版”、“抢鲜版”
用发布证书
不能用XCode调试，不能设置断点
不过可以通过XCode安装。运行时会闪出来
能用iTools等工具在手机上安装，手机不需要注册UUID
也可以放在企业内网，下载安装
不能上传AppStore

关于友盟统计

一开始，友盟统计的AppKey是跟bundle id相关的；这样的话，引入企业版就要申请新的AppKey
估计企业版用于内测比较多，除了bundle id不一样，其他功能跟正式版都一样，那么把bundle id作为区分条件就不合适
当前的友盟统计的AppKey跟bundle id无关；这样的话可以自己决定是否需要新建AppKey。
简单处理就不要新增了，跟正式版用同一个；
如果要区分渠道：正式的还是内测的，那么就新建一个。

关于分享

新浪微博分享，一个AppKey下面可以挂最多4个bundle id，所以可以不新增。
微信分享，一个AppKey可以挂2个bundle id，另外一个的名字叫测试bundle id。看来是专门用来拿企业版当内测版的
QQ分享，有AppKey和AppID两个参数，不知道为什么这么设计。从网站介绍来看，AppID好像跟bundle id有关。经过实际试验，其实他的处理方式和友盟统计一样：AppID和bundle id无关
小结：微博，QQ，微信这三个分享，都可以做到企业版和正式版用相同的AppKey，可以简单地把企业版当做“内测版”。
当然，如果要精细化管理，区分数据来源，那么用不同的AppKey来做也是可以的。只是模式太多，版本太多，管理上面要多花点心思。

关于极光推送

这个没有办法，需要上传推送证书。所以AppKey跟bundle id是强相关的。这种相关是苹果的证书生成方式决定的，在可预期的未来也很难改变。
企业版和正式版，是完全不同的应用，虽然功能是完全一样的。

需要几个版本？

开发版：（AppStore Debug模式）开发和测试使用，测试负责维护服务器数据。开发可以用工具造数据，比如Charles；也可以在本地自己写测试数据，只是不要忘了到时候删除测试代码。建议的方式还是测试和开发合作，由测试提供核心案例数据，开发和测试标准统一。
内测版：（企业账号 Release模式）一般有两种用法：（1）测试维护，用来测试和内部验收。（2）运营维护，真正的内测版，服务器环境和正式版本一致，但是独立的服务器，和正式环境隔离。
审核版：（AppStore Release模式）这个版本专门给苹果审核用。服务器环境和正式版本一致，但是独立的服务器，并且只是1个或者2个测试账号，（用户数最好不要超过10个），注册，短信验证码之类的流程都不要产生。并且，面对审核，有些特殊的要求，比如IPv6服务器等等。同时，苹果审核通过之后，不能自动上架，要手动上架。服务器的开关切换放在后台，手动上架前要把服务器地址切换到正式的。
正式版：（AppStore Release模式）。这是“产线版”，基本上都是有的。

大前端趋势

JavaScript有一统江湖的迹象，iOS、Android开发都准备转JavaScript前端开发，至少思想上需要有这样的趋势。
facebook 的React Native；阿里的 weex， Google的 PWA，这些大公司都在跟苹果争夺开发者。iOS开发者地位下降，需求降低，薪资走低，苹果的影响力控制力降低，这些都是正在发生的事情。
库克比乔布斯差的不是一点点，从iOS开发者的生存状态就可以看出来。
PC 前端：主要是浏览器的网站
H5 前端：微信小程序，支付宝生活号，微信公众号，App中的活动，也可以尝试一下 Google的 PWA
App开发：iOS、Android组件开发，这些还是原生的。facebook 的React Native，阿里的 weex选择一个。以前用H5写的活动页面，也可以用weex（或者React Native）来实现。
网关开发：大前端里面的后台，后端系统的前端接口层。采用Node.js来做，也是JavaScript。这一层的价值是“大前端”和“大后端”之间的接口层。与后端，是纯的“数据接口”；这一层主要是负责对各端数据格式做适配（比如浏览器的换行是，原生的换行是\n）。

建议的流程

改进点：一般都是后台系统准备好了，在提供数据给前端联调，导致前松后紧，为上线加班。现在将整个流程分为内部发布，内部试用，苹果审核，正式上线4个阶段，减少无意义的加班。

内部发布:在开发分支上开发新特性，develop，数据由“网关开发”提供。能接实际后台的就接上，比如用户系统。后台提供不了的，那么就由测试根据核心测试案例构造一些，直接以url为key，value就是前端需要的json，直接放在“缓存数据库”中。保证各端都是可用的产品，没有本地写死的Demo数据。开发测试完成之后，就可以内部发布，将版本转移到发布分支。格式为alpha-年年月月日日。产品部门可以验收，试用，看看是否符合设计，完成后就可以进入下一个开发周期。一个周期建议4周（1周理解需求和方案设计，2周开发测试，1周和产品部分交流合作，并未下个研发周期做准备）。当然，采用2周的开发周期也是可以的，只是要求部门间配合要做好。
内部试用：这个要看后台的进度。那些由“网关开发”提供的临时json数据都接上真正的后台数据，再经过测试验证，就可以发布“内测版”。这个内测版最好使用企业版账号的Release模式。这个阶段主要是后台开发的实现以及“网关开发”接口的调整。前端方面，只要将某个合适的alpha-年年月月日日转以为beta-年年月月日日就可以了。当然，由于接上真正的后台，可能会导致前端的调整。并且这段时间也会发现新的bug，只需要直接在beta-年年月月日日这个分支上修改。至于修改是否同步到develop分支，要根据具体情况而定。
“内部试用版”由于采用了企业版账号，就比较灵活，可以直接放在自己的网站上（需要支持https），让相关人员下载试用。这个版本的服务器独立，各方面和真实服务器一致，主要由运营负责。一些活动，一些推广的方案，可以内部先试用一下，看看效果，及时调整。试用的时间长短，是否正式推向市场，这里还有讨论和调整的机会。
苹果审核：经过内部试用，终于决定上线了。苹果审核与正式使用的场景还是有很大差异的。前端的代码是一样的，从某个beta-年年月月日日转到release-年年月月日日就可以了。服务器要单独提供一个，配置和正式的一样，不过要为审核做一些特殊处理。比如支持IPv6，提供测试账号，不能出现Android字样等等。为了满足苹果审核要求，可能会需要做一些修改，直接在release-年年月月日日分支上操作就可以了。至于是否将修改同步到develop分支，要根据具体情况而定。
正式上线：经过等待和必要的修改，苹果审核通过了。（1）运营或者运维登录自己的后台，将服务器从苹果审核服务器切换到正式服务器。如果用户量大，或者考虑稳定性，这里可以引入“灰度发布”，逐步放开用户量。（2）登录苹果开发者网站，手动上架产品。
将上架产品对应release-年年月月日日，合并到master分支。如果由"灰度发布"机制，需要等用户全量放开才能合并。这段时间如果发现bug需要修改，直接在这个release-年年月月日日分支上操作。这里的修改是否合并到develop分支，需要根据具体情况而定。
合并到master分支，意味着一个完整周期走完了。master分支和稳定的正式版本保持一致。

master分支和develop分支是必须的，不可删除，权限要特殊控制。alpha/beta/release-年年月月日日都属于中间辅助分支，保留一段时间后，比如半年，可以删除。当然，都留着也是好的，每个过程都有里程碑标志，方便追溯。

一开始，要错开步骤，需要一点启动时间，看起来要慢一点。完整运行起来之后，各个过程是完全独立的，并且各自负责的部门主体也不一样，是完全可以并行的，一点也不慢。

这里的本质是前端能够提供一个最小可用版本，按照自己的节奏发展，不需要干等后台数据。（依赖后台数据的后果：前面没法做，后面累成狗，加班上线后还要解线上bug，还有临时的需求变更.... ）。

核心优势1：技术和产品合作，倒逼运营养成提前规划的习惯。反问：2周前提出，2周后就上线，这样匆忙能作出一个好的活动吗？风险能控制吗？阿里的双十一会这么做吗？

核心优势2：方便领导审批。一份word文档就让领导放成千上百的资金，压力大吗？如果领导能够看到可用的产品（alpha版本），是不是审批时可以简单点？

核心优势3：风险提前发现。推出给最终用户之前，先在公司内部试用一段时间（beta版），就算一周或者两三天也比没有强，是不是更能控制风险，对用户更加负责？这个是不是比光靠测试把控产品质量更靠谱一点？

核心优势4：更多试错的机会。运营策划一个活动之后，可以和产品和技术商量，大家觉得可行，就可以先开发出一个版本看看效果（alpha版），不需要等领导审批之后再动。有实际可用的产品，领导审批也更方便，也更容易过。（alpha版）不涉及后台开发，就算废掉，成本也不高。试错机会多了，出好产品的概率会高一点。

核心优势5：更快的迭代速度。不用等后台实现，迭代版本速度就可以加快。前端和产品可以更紧密合作，加快产品演进速度。到用户手里的版本，在公司内部可能已经更新了三四个版本了。至少不会出现“最近后台任务比较重，前端任务比较少，只能干等着的情况。”

组织架构

技术架构和流程，需要相应的组织架构来支持。组织架构，还是采用传统的分层模式，这个稳定，有归属感。而具体做事的时候，采用4~10人的小团队模式，这个灵活，以团队目标为主，防止个人英雄主义。

组织架构图.png

产品一开始人少，可能就1~2个，可以先挂在技术下面。并且和客户端团队走得近，对以后的小团队模式有帮助。发展壮大之后，一般会独立成一个部门。形成产品，技术，运营的三角关系。
“Node.js网关”和“客户端数据服务”这两个是客户端和后端的接口，也是将两者分离的交接点，是两位负责人最需要关心的地方。一方面，统一出口，前后端隔离；另一方面，等用户量大起来之后，要注意单点风险。所以这两个模块，要定义需要做什么，更要定义不做什么。公共部分要做，具体实现尽量甩出去
CTO应该是纯管理，怎么和CEO配合好事首要问题。当然，技术方向也要把控。
客户端负责人和后端负责人，一般是前后端的架构师兼任。属于重要的中层。以流程管理和架构技术为主，跟紧发展潮流，同时也应该花30%左右的时间做技术实践，保持熟练度。
测试和运维属于公共服务，可以单独出来
iOS和Android，面对的是两种手机客户端。可以先各找一个，当然也可以先发展一个，等稳定了再上另外一个。界面和交互，两个端也不需要强调一致。两种手机发展理念是不一样的。
H5，可以是App中的WebView页面，也可以是微信小程序，支付宝生活号等等。根据需要来吧。
Node.js是后台技术，但是放在客户端，主要为多端数据展示做数据适配等工作。也可以做一下公共逻辑，比如日志，加解密，统计，以及其他公共业务逻辑。和具体客户端无关的逻辑放在这里，只要实现一遍，各种端都能受益。另外，这个主动权掌控在自己手中，不受客户端是否升级影响，也不会受限制于苹果审核机制。更重要的是，客户端一般处理单页面单用户逻辑，而这里，则不受这两点限制，发挥空间很大。另外，这里虽然用后台的技术，但是要有客户端的思维，为客户端开发闭环做好服务。现在JavaScript发展势头很猛，在这里可以很好地发挥一下。
Node.js网关（数据消费者）和Java数据服务（数据生产者）之间，是纯粹的数据信息通信，不要考虑各种端的差异。比如时间戳，只要一个long数据就可以，不需要考虑是年月日还是时分秒等具体表现形式。这里基本不需要“文艺青年”的参与，纯粹是技术内部“鸟语”。
至于是否要引入React Native，weex等，看需要吧。个人认为是不需要。现在苹果的审核已经很快了。把随心所欲升级当做需求是耍流氓。另外，多端一致，全栈工程师，少招几个开发之类的领导爱听的话，纯粹是损人利己的行为。
当然，产品、运营一天到晚要搞活动，热更新，那确实需要H5，如果还要求体验，React Native，weex也是有一定价值的。面对流氓，也只能耍流氓了。
真正的动态性，正在的提升效率，将公共逻辑移到Node.js网关才是正解。“云 + 轻客户端”才是让企业掌握主动的方式。