Честно говоря, связку windows + unity мы не рассматривали, т.к. пока что не было такой необходимости. Но если использовать серверное решение, аналогичное нашему, то реализовать клиентскую библиотеку с кэшированием данных в оффлайне — задача не особенно сложная.
Саш, какие именно параметры анализируются — описано в предыдущем посте про статистику. Дополнительно к этому настраиваются game-specific метрики, которые могут сильно зависеть от каждой конкретной игры.
С большими объемами данных спланк справляется без проблем, при помощи сохраненных поисков с кэшированием результатов.
Т.е. сначала мы отлаживаем выборки на небольших временных интервалах (1-2 дня), затем настраиваем запуск запроса по крону + кэш. И на всех отчетах/дашбордах уже используются закэшированные результаты.
Там, где у нас идет разработка, мы используем DVCS, а для решения задачи «принять версию исходников от внешней студии разработки, с которыми мы ничего кроме компиляции не делаем», Subversion-а хватает за глаза и по уши.
Внешние разработчики вольны использовать в своих студиях какие угодно СКВ, а нам достаточно только принять у них слепок, фиксирующий майлстоун.
XCode-плагин не используем, т.к. когда мы только начинали все это разворачивать, уткнулись в две проблемы:
1. не было возможности явно сказать xcode-у какими сертификатом и провиженом подписывать билд, а с командной строки — легко
2. не было возможности выбирать версию xcode
Возможно в текущей версии плагина это уже решено, не уточнял.
Схема версионирования у нас достаточно проста — при сборке мы к маркетинговой BundleVersion добавляем номер ревизии (было 1.0, делаем 1.0.39).
bash-скрипт — это только часть всей системы сборки, которая непосредственно запускает XCode.
Для небольшого парка девайсов и 5-10 приложений в разработке можно вообще ограничиться простейшим набором bash и php скриптов, которые будут собирать IPA, генерить для нее манифест и ссылку для OTA-установки.
Это уже тэгирование собранных билдов, а мы ищем тэг в commit message и запускаем сборку только тех ревизий, которые разработчики обозначают готовыми к QA.
Тэги в AirOnApp удобны для сохранения истории релизов-апдейтов в стор, чтобы QA могли проверифицировать, например, сохранение прогресса при выходе апдейта.
elmm, нам, как издателю, не особенно интересна вся история изменений разработки проекта, а важны майлстоуны.
Для непосредственных коммуникаций между QA и разработчиками у нас есть Jira.
С большими объемами данных спланк справляется без проблем, при помощи сохраненных поисков с кэшированием результатов.
Т.е. сначала мы отлаживаем выборки на небольших временных интервалах (1-2 дня), затем настраиваем запуск запроса по крону + кэш. И на всех отчетах/дашбордах уже используются закэшированные результаты.
Внешние разработчики вольны использовать в своих студиях какие угодно СКВ, а нам достаточно только принять у них слепок, фиксирующий майлстоун.
1. не было возможности явно сказать xcode-у какими сертификатом и провиженом подписывать билд, а с командной строки — легко
2. не было возможности выбирать версию xcode
Возможно в текущей версии плагина это уже решено, не уточнял.
Схема версионирования у нас достаточно проста — при сборке мы к маркетинговой BundleVersion добавляем номер ревизии (было 1.0, делаем 1.0.39).
Для небольшого парка девайсов и 5-10 приложений в разработке можно вообще ограничиться простейшим набором bash и php скриптов, которые будут собирать IPA, генерить для нее манифест и ссылку для OTA-установки.
Тэги в AirOnApp удобны для сохранения истории релизов-апдейтов в стор, чтобы QA могли проверифицировать, например, сохранение прогресса при выходе апдейта.
Для непосредственных коммуникаций между QA и разработчиками у нас есть Jira.