Несколько версий APK с разным функционалом

Ваш вопрос действительно слишком широк, я думаю, что нет общего решения вашей проблемы, потому что она слишком сложна, а без знания деталей проекта решить ее еще сложнее. На самом деле, ваша проблема больше похожа на организационную, чем на программную, единственное «решение», которое я вижу, это решение конкретных вопросов.

<сильный>1. Нет VCS, нет вечеринки

таких версий может быть несколько (от 3 до 10), и все они разрабатываются одновременно несколькими разработчиками в одном проекте в одном репозитории.

Я бы начал с определения вашего потока VCS, потому что без системы контроля версий, боюсь, вы и ваша команда никуда не денетесь. Если бы вы использовали git (не знаю, как это будет сделано с другими системами контроля версий), у вас было бы несколько вариантов:

1. У каждой фичи (команды) есть своя, долгоживущая, фича-ветвь. Общий код, используемый всеми командами, хранится в ветке разработки, на которую периодически перебазируется каждая функциональная ветка. Вам нужно будет настроить CI для создания тестовых apk и запуска автоматических тестов для каждой ветки. В конце процесса разработки все объединяется с мастером (или разработкой, или чем-то еще). Преимущество будет заключаться в том, что каждая функция (команда) будет работать над закрытой частью проекта и сможет автономно обрабатывать тестовые выпуски и автоматизированные тесты. Недостатком будет то, что с общей частью кодовой базы (ветка разработки) нужно обращаться очень осторожно, иначе вы можете получить ад конфликтов.

2. Весь проект разрабатывается на общей ветке development. Каждая функция разрабатывается с небольшими приращениями, каждый член каждой команды переходит из ветки разработки и объединяет каждую итерацию обратно в ветку разработки. Преимущество будет заключаться в следующем: разные функции могут потенциально зависеть друг от друга, меньше вероятность возникновения конфликтов, CI имеет более простую конфигурацию. Недостаток: команды менее независимы, выпуск разных apk требует стратегии.

<сильный>2. Определить зависимости

Чтобы выбрать правильную стратегию, очень важно четко определить зависимости между функциями. Возможна ли по-настоящему параллельная разработка каждой функции?

Это полностью зависит от спецификации проекта. Например, если вы разрабатываете приложение для электронной коммерции, у вас могут быть домены функций, такие как учетная запись пользователя, каталог продуктов, обработка заказов... Если все эти функции зависят от общего уровня локального хранилища, как вы собираетесь развивать их действительно параллельно?

Как только вы определили зависимости, вы сможете решить, в какой степени функции могут разрабатываться параллельно. Нужно ли разным командам согласовывать общие интерфейсы? Может ли функция быть завершена, даже если другие команды все еще на 0?

<сильный>3. Варианты сборки — ваш друг

разные «тестовые» версии APK не должны содержать НИ ОДНОГО кода и ресурсов (поэтому никаких общих строк и изображений) из других версий APK (по соображениям безопасности/реверс-инжиниринга, потому что разные люди будут иметь доступ к разным версиям APK)

Ароматы предназначены для того, чтобы делать именно то, что вы ищете, то есть создавать разные apk из одного и того же проекта, но с использованием разных подмножеств кода и/или ресурсов.

Имейте в виду, что у вас могут быть варианты в нескольких измерениях (и типах сборки). Например, у вас может быть одно измерение аромата под названием «сеть» с двумя ароматами «mockedNetwork» и «actualNetwork». Тогда у вас может быть другое измерение «функция» с «функция A», «функция B», «функция C». Затем вы можете легко создать и выпустить 6 типов (хорошо 12, если у вас также есть типы сборки отладки и выпуска) apks, по одному для каждой комбинации (mockedNetworkFeatureA, factNetworkFeatureA, mockedNetworkFeatureB и т. д.).

С помощью ароматов вы можете легко заменить фрагменты приложения, которые вы не хотите, чтобы ваш тестер имел. Например, у вас может быть файл strings.xml, содержащий только строки lorem ipsum, а затем сохранить фактические текстовые строки только для внутреннего использования.

Я бы использовал git. Основная ветка поддерживается в чистоте для производства, и каждая команда может иметь одну или несколько веток для работы. Они могут изменить имя пакета в своей ветке, поэтому все ваши APK будут разными. Единственной проблемой при таком подходе будут слияния с основной веткой, которые могут вызвать конфликты. Но это может быть решением вашей проблемы.