7. Контроль качества кода
• Не заменяет ревью
• Есть сомнительные ворнинги
• Нужен консенсус в команде и настройка правил
• Тесты никто не пишет ( ◔ ʖ̯ ◔ )
12. Версионирование
• Независимое для каждой поставляемой ветки (test, release,
etc)
• Базируется на названии ветки и номере билда
• ${BUILD_NUMBER} = 34
• CFBundleVersion = 0.3.34
• CFBundleShortVersionString = test-34
• Версия видна пользователю (тестировщику): внутри
приложения, на иконке
• Версия видна разработчику: тег в гите, отчёты об ошибках,
логи
13. Changelog
• Облегчает поиск нужной версии и процесс
тестирования
• Варианты составления
• “Руками”
• git log
• ссылки на тикеты / документацию
• гибридный (?)
14. Дебаг-символы
• ProGuard mapping.txt для Android
• .dSym.zip для iOS
• Отсутствие существенно усложняет диагностику
крешей
• Легко теряются если сборка проводится на
локальной машине
17. Подводные камни
• Поддержка работоспособности (обновление)
• Требования к окружению для разных проектов
• Поддержка масштабируемой системы
• “Сакральные знания”
19. Креш-репортинг
• Сбор символов для расшифровки стектрейсов
(mapping.txt/dSYM.zip)
• Интеграция SDK
• Уведомления о крешах
• Интеграция с багтрекером
• Дополнительные данные (логи, app state)
• Не только креши (зависание главного треда,
обычные ошибки)
20. Решения
• Стандартные решения (ITC, Play)
• HockeyApp
• iOS: KSCrash
• Android: ACRA
• Коммерческие решения (Crashlytics, etc)
21. Багрепорты
• Shake to report (rage shake)
• Отправка через email / багтрекер
• Сборка данных
• Описание пользователя
• Скриншот
• ViewHierarchy
• Состояние приложения
• Логи
28. • Особенности релизной конфигурации
• Многочисленные пересборки из-за замеченных в
последний момент мелочей
• Человеческий фактор и дурацкие ошибки
День релиза
29. Способы борьбы
• Более частые релизы
• Релизный чеклист для разработчика
• Релизная конфигурация для системы сборки
• Тестируем релизный бинарник