0

我正在开发和应用程序(在开发和测试过程中,但不是在最终版本中)在不同的 .apk 发布文件中需要稍微不同的功能。

在这种特殊情况下几乎没有问题:

  • 不同的“测试”APK 版本不应包含来自其他 APK 版本的任何代码和资源(因此没有共享的字符串和图像)(出于安全/逆向工程原因,不同的人将可以访问不同的 APK 版本)
  • 在开发过程结束时,应用程序将包含来自“测试”版本的所有/大部分功能。
  • 该应用程序使用多个模块(由不同团队开发)
  • 这些版本中可能有几个(3 到 10 个),它们都是由多个开发人员在同一个存储库的同一个项目中同时开发的。

目标是使其尽可能易于维护(包括 UI/集成测试和 CI)。有什么办法可以做到这一点?我们用不同的构建变体和风格+无操作模块/方法做了一些实验,但看起来有点复杂。欢迎任何替代建议。

4

2 回答 2

2

您的问题确实太宽泛了,我认为您的问题没有通用的解决方案,因为它太复杂了,并且在不了解项目细节的情况下更难以解决。实际上,您的问题听起来更像是组织问题而不是与编程相关的问题,我看到的唯一“解决方案”是解决特定问题。

1.没有VCS,没有派对

这些版本中可能有几个(3 到 10 个),它们都是由多个开发人员在同一个存储库的同一个项目中同时开发的。

我将从定义您的 VCS 流程开始,因为如果没有版本控制系统,恐怕您和您的团队将无处可去。如果您要使用git(不知道如何使用其他 VCS 来完成),您将有几个选择:

  1. 每个特性(团队)都有自己的、长期存在的特性分支。所有团队共享的公共代码都保存在一个开发分支上,每个特性分支都会定期在该分支上重新建立基础。您需要设置 CI 来构建测试 apk 并为每个分支运行自动化测试。在开发过程结束时,所有内容都会合并到 master(或 development,或其他)中。优点是每个功能(团队)都将在项目的密封部分上工作,并且能够自主处理测试发布和自动化测试。缺点是代码库的公共部分(开发分支)需要非常小心地处理,否则您可能会遇到冲突地狱。

  2. 整个项目是在一个共同的开发分支上开发的。每个功能都是以小增量开发的,每个团队的每个成员都从开发分支分支,并将每个迭代合并回开发分支。优点是:不同的功能可能会相互依赖,不太可能发生冲突,CI 的配置更简单。缺点:团队独立性较差,发布不同的apk需要策略。

2.定义依赖

为了选择合适的策略,明确定义特征之间的依赖关系至关重要。是否有可能对每个功能进行真正的并行开发?

这完全取决于项目的规范。例如,如果您要开发一个电子商务应用程序,您最终可能会拥有用户帐户、产品目录、订单处理等功能域……如果所有这些功能都依赖于通用的本地存储层,那么您将如何真正并行开发它们?

一旦定义了依赖关系,您将能够决定可以在多大程度上并行开发这些功能。不同的团队是否需要就通用接口达成一致?即使其他团队仍然为 0,是否可以完成一个功能?

3.构建变体是你的朋友

不同的“测试”APK 版本不应包含来自其他 APK 版本的任何代码和资源(因此没有共享的字符串和图像)(出于安全/逆向工程原因,不同的人将可以访问不同的 APK 版本)

风味旨在完全满足您的需求,即从同一个项目构建不同的 apk,但使用不同的代码和/或资源子集。

请记住,您可以拥有多个维度(和构建类型)的风味。例如,您可以有一个称为“network”的风味维度,具有 2 个风味“mockedNetwork”和“actualNetwork”。然后你可以有另一个维度“特征”,有“特征A”、“特征B”、“特征C”。然后,您可以轻松构建和发布 6 种类型(如果您还具有调试和发布构建类型,则为 12 种)apks,每种组合一个(mockedNetworkFeatureA、actualNetworkFeatureA、mockedNetworkFeatureB 等)。

使用风味,您可以轻松替换您不希望测试人员拥有的应用程序块。例如,您可以有一个仅包含 lorem ipsum 字符串的 strings.xml 文件,然后保留实际的文本字符串仅供内部使用。

于 2018-03-01T21:12:35.023 回答
0

我要做的是使用git。主分支保持清洁以进行生产,每个团队可以有一个或多个分支来工作。他们可以在他们的分支中更改包名称,这样您的 APK 就会完全不同。这种方法的唯一问题是合并到可能导致冲突的主分支。但这可能是您问题的解决方案。

于 2018-02-23T15:54:42.543 回答