0%

从无到有,开发一个 App(三)--- 多人协助开发APP快速交付

按照我司的现实情况来讲,app 团队基本上维持着一个 10 人以上的移动研发团队,团队里面有项目经理、开发和测试同学,在研发过程中基本上都是多个项目同时进行。在项目的发展中,其中有些项目会参与到各种运营活动之中,需要和其它团队进行协作。所有的代码都耦合在一个客户端里面,每个月至少要发布 2 个版本,大家开发周各自开发暂时相安无事,一旦到了测试周要合代码到一起就出现各种诡异问题导致构建不成功、功能不可用、测试需要反复无数次验证依然惴惴不安。如何才能更好地协作开发,以较高的效率完成 App 开发工作呢?

迭代的典型流程

Alt text

上面是一个应用开发的典型流程图,下面来对流程进行详细的分析。

规划

  • 工程解耦
    对于 10 人以上的研发团队,非常需要提高研发协同效率,首先工程需要解耦,各自独立,减少相互依赖和影响,尽量做到每个模块可以独立构建独立发布。在开发中我们也采用了这样的方式,将客户端代码,基础库(网络库等),App 内 使用到的 Web 页面代码分别建立成独立的仓库,在未来应该也会将运营活动的页面和代码建立独立的工程来管理。

  • PMO(Project Management Office):定义项目规范和版本计划
    PMO 作为统筹整个项目的关键环节,先根据团队人员配比等制定适合当前团队的项目管理方案和项目规约,同时定义清楚客户端版本发布计划,例如每周五发布一个灰度版本,每个月底发布一个正式版本,计划清晰后同步到所有人员,方便大家安排工作。

  • 产品经理:设计需求
    产品经理通过分析用户反馈、分析市场诉求,从而抽象出业务需求,研发人员也会自行添加技术升级类需求,统一沉淀到平台做需求管理。当然,在实践中研发人员自行提出的技术需求需要和项目经理以及测试人员进行会商,评估影响面积,风险敞口,测试工作量和测试资源的安排。

  • 项目经理:排期分工
    根据需求和版本计划,PM 应将需求拆分成多个并行项目,如技术改造项目、迭代需求项目、长线需求项目,运营活动项目,项目经理或者资深研发会把这些需求细化拆分成任务,分派给不同的具体开发人员。

开发

  • 研发:代码变更
    研发实现需求后,在各自研发项目和代码分支中添加变更,测试自己的变更,当然最好是能对公共部分代码添加或者补充单元测试用例以保障项目的质量。

  • 研发:持续集成(CI)
    使用 CI 解决方案配合构建脚本在开发过程中持续进行构建集成和单元测试,及时发现问题,尽可能将能发现的问题在开发阶段解决。

  • 研发:版本集成
    研发在项目空间中完成代码变更和测试后,按照约定的发版计划,再约定好的时间自行提交版本集成生成最终提供测试冒烟的版本。

测试

  • 测试:功能、验收测试
    参加集成后,测试会对最终集成完成准备发布的包进行功能回归和验收测试,只有测试通过后的包,才能发布到用户手中。

发布和运维

  • 研发:版本发布
    版本发布过程,支持丰富的灰度策略,需要支持多批次缓慢放量,发布过程中实时监控 Crash、用户反馈,发生问题可及时止血。在我们的实践中,灰度策略基于 3 个维度,分别是具体客户、客户端版本、ReactNative 版本。客户维度基于客户号实现,客户端和 ReactNative 版本都基于客户端上报的请求头来实现。更复杂的维度甚至可以包含系统版本,手机型号等等。对于一些功能发布出现问题时可以及时将灰度关闭,停止功能的发布上线,将影响降低。
    在 ReactNative 版本发布的过程中,由于我们的发布窗口在周五,我们采用先对占用户比重较小的新近原生版本放量发布,如果在周末没有大面积的异常情况出现,则在周一对其余的存量旧版本进行发布升级。出现问题的话,可以及时进行版本的回滚,减少问题的影响面积。

  • 研发:运维监控
    线上监控运维,除了实时 Crash 分析之外,还应提供线上问题快速定位分析的解决方案,用户日志跟踪等服务,方便及时发现问题。成熟的解决方案有 MTA,Bugly 和友盟等等开发商提供的 SDK。

控制迭代的节奏

在我们的具体实践中,迭代的具体步骤大致如下图所示。

Alt text

开发周

  1. 周一对上一个迭代周期的发布进行全量发布配置。
  2. 开发人员对本迭代需求进行开发,测试人员进行本迭代测试用例的编写
  3. 周五进行本迭代发布需求的测试用例评审

测试发布周

  1. 周一上午开发将需在本迭代发布需求的代码分支进行合并,并通过构建。
  2. 周一下午测试人员将开始对开发成果进行冒烟测试。
  3. 冒烟测试通过后,开始为期四天的迭代测试。
  4. 在周四,PM召集产品经理和开发负责人讨论并定稿下一迭代需求。
  5. 周五中午锁定开发分支,后续任何提交均需要进行审批。(防止有无限多的修改导致版本质量不可控)
  6. 下午进行回归测试和最小检查点测试。
  7. 晚上进行新版本的发布并对发布代码版本打 tag,发布完成之后进行新近版本的升级配置。

最后的话

以上三篇,算是对这几年客户端工作的梳理,也是对经验的一个总结。真正的移动应用开发大潮始于 2007 年 Apple 发布 iPhone 到现在已经过去了 12 个年头。这 12 年里设备在不断创新进步,移动应用开发的技术也在一步步向着成本更低,更可维护的方向发展着。我们也看到前端技术和客户端技术的大融合催生的一系列创新的技术方案,这些技术创新也在一定程度上推动着业务和开发流程的演进和发展。希望通过这几篇文章的分享能够给予刚进入移动应用开发领域的参与者一些有建设性的观点,以更好的方式,开发出更好的应用。