Принципы основаны на известной методологии от heroku, адаптированы под реалии айос разработки (Отсутствие контейнеров, ревью которые занимают несколько дней и тормозят развертывания, работа Xcode только на маке).
Эта статья является коротким введением, полную серию можете найти на iOS-factor, так же доступен русский перевод. Проект iOS-factor с открытым исходным кодом на github, постоянно дорабатывается и приветствует новые идеи. Я так же принял участие в его развитии. Проект основан Феликсом который является создателем fastlane.
TL;DR
- Зависимости: Должны быть явно и конкретно указаны (версия Xcode, CocoaPods, версия зависимостей в podfile). Это дает возможность воспроизвести билд на любом маке новому разработчике. Так же повторить сборку которая использовалась 6 месяцев назад.
- Конфигурация: Нет конфигурации в коде, поставляется вместе с приложением и возможность обновить по воздуху
- Паритет разработки/работы приложения: Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими
- Развертывания: Автоматизировать деплой, чтобы вы могли выпускать его с любой машины.
- Локальный против бека: Держите приложение iOS универсальным, чтобы по возможности работать без бэкэнда
- Обратно совместимые API: Не думайте, что каждый пользователь обновляется до последней версии
- Управление версиями приложения: Автоматизировать поднятие версий и билдов
- Откаты: Откат сборки, которая вызывает проблемы
- Хранение данных: Следуйте рекомендациям Apple при хранении данных
Зависимости
Приложение объявляет все свои зависимости полностью и точно с помощью манифеста декларации зависимостей.
Это включает себя конкретную версию Swift, Xcode, CocoaPods, Carthgae и Fastlane. Так же все зависимости в podfile и cartfile должны указать конкретную версию.
Одним из преимуществ явного объявления зависимостей является то, что это упрощает настройку приложения для новых разработчиков.
С помощью указание конкретных зависимостей, вы сможете воспроизвести билд который использовался 6 месяцев назад, зная что он соберется потому что билд будет использовать такую же версию Xcode, CocoaPods и Swift.
Ограничение — Поскольку разработка iOS не может быть заключена в контейнер, как это уже используется для веб-разработки, мы ограничены сторонними инструментами, пытающимися выполнить это требование, пока Apple не предоставит официальное решение. Существует стороннее коммерческое (закрытое) решение, называемое Veertu это позволяет вам создавать виртуальные среды MacOS на оборудовании Apple.
Конфигурация
Код не зависит от окружения, а конфигурация зависит. Поэтому код должен храниться в репозитории, а конфигурация в окружении. Проверкой того, правильно ли разделены конфигурация и код приложения, является факт того, что кодовая база приложения может быть в любой момент открыта в свободный доступ без компрометации каких-либо приватных данных.
Существует множество способов ввода значений конфигурации во время сборки
- Файлы конфигурации (JSON или YAML файлы)
- cocoapods-keys чтобы спрятать ключи и применить их к вашему iOS-приложению во время сборки
- Индивидуальное решение (например, с использованием build phase)
Поскольку развертывания на платформе iOS значительно медленнее, чем на серверах, вам может потребоваться способ обновления конфигурации по воздуху (OTA — over the air) для быстрого реагирования на проблемы.
Обновления конфигурации OTA позволяют вам мгновенно:
- Запустить A / B-тесты, чтобы включить определенные функции или изменения пользовательского интерфейса только для части активных пользователей.
- Изменить API ключи
- Обновите веб-хосты или другие URL-адреса, которые изменились
- Удаленно отключить функции или скрыть кнопки
Некоторые потенциальные подходы при реализации OTA-обновлений:
- Реализуйте свое собственное решение
- Готовые решения по типу Firebase remote config
- Сервис с открытым исходным кодом, как FeatureFlags
Паритет разработки/работы приложения
Исторически существуют значительные различия между разработкой (разработчик делает живые изменения на локальном развёртывании приложения) и работой приложения (развёртывание приложения в App Store с доступом к нему конечных пользователей).
Эти различия проявляются в трёх областях:
- Различие во времени
- Различие персонала
- Разрыв в инструментах:
Решение:
- Сделать различие во времени небольшим: разработчик может написать код, и он будет развёрнут через несколько часов или даже минут.
- Сделать небольшими различия персонала: разработчик который написал код, активно участвует в его развёртывании и наблюдает за его поведением во время работы приложения.
- Сделать различия инструментов небольшими: держать окружение разработки и работы приложения максимально похожими.
Развертывания
Как описано в принципе Зависимости, репозиторий кода должен включать все зависимости, необходимые для создания, тестирования и развертывания iOS приложения.
К сожалению, из-за того, что Xcode должен работать на MacOS, мы не можем использовать контейнеры как на вебе. Запуск macOS в виртуальной среде сопряжен с техническими и юридическими проблемами.
Прямо сейчас лучший подход, который мы, разработчики iOS, можем использовать:
- Автоматизировать установку Xcode с помощью xcode-install
- Использовать .xcode-version file указать точный релиз Xcode
- Определите все зависимости в конфигурационных файлах (смотрите Зависимости фактор)
- Автоматизировать весь процесс развертывания, используя fastlane
- Автоматизировать подпись приложения (codesigning.guide)
- Релизить часто, в идеале по недельному графику
Многие компании используют концепцию Release trains: расписание, в котором выходит новая версия вашего приложения. Весь код, который был объединен с вашей основной веткой (master или release) в тот момент, когда релизный поезд «уходит» будет отправлен в App Store. Этот подход реализуется большинством крупных приложений для iOS.
Локальный против бека
В последние годы некоторые группы разработчиков начали использовать подходы, которые требуют меньше усилий по разработке, за счет снижение качества user experience, перенеся больше логики на бэкэнд и сделав приложение iOS тонким клиентом, показывающим результаты сервера.
Приложение должно выполнять как можно больше бизнес-логики и вычислений на устройстве по целому ряду причин:
- Конфиденциальность: избегайте отправки данных на удаленный сервер
- Скорость: отправка данных на сервер и ожидание ответа требует времени и может привести к сбою (например, плохой WiFi)
- Использование данных: пользователи часто имеют месячные лимиты данных
- Масштабирование: если ваше приложение становится популярным, вы несете ответственность за расширение масштабов бэкэнд-сервисов
- Срок службы батареи: использование мобильных данных обходится дорого
- Надежность: в некоторых странах все еще плохое соединения LTE / 3G
Если вашему приложению требуется подключение к Интернету для всего функционала (например, приложение для социальных сетей или приложение для обмена поездками), оно должно по-прежнему работать (в режиме только для чтения) без подключения к Интернету для доступа к историческим данным (например, недавние поездки, недавние прямые сообщения).
Обратно совместимые API
Хотя большинство ваших пользователей будут обновляться до самого последней версии в течение нескольких недель, всегда найдутся пользователи, которые этого не сделают. Это может иметь несколько причин. Часто это связано с используемой версией iOS, которую они не всегда могут обновить из-за возраста устройства.
Основная концепция заключается в том, что вы не обновляете существующий API, а вместо этого добавляете новый и позволяете им работать параллельно
https://your-api.com/1.0/drivers.json
https://your-api.com/1.1/drivers.jsonУправление версиями приложения
Версия и номер билда используются вместе что бы идентифицировать конкретное приложение в аппсторе
- Номер версии
(CFBundleShortVersionString)— показан как Version в Xcode - Номер билда
(CFBundleVersion)— показан как Build в Xcode
В сегодняшней разработки под iOS нет причин, по которым вы должны вручную менять эти цифры. Вместо этого вам нужна надежная и автоматизированная система, обеспечивающая актуальность версий.
Xcode имеет встроенный инструмент под названием agvtool.
Откаты
App Store изначально не допускает откатов, поэтому в этом разделе описывается, как добиться аналогичных результатов, используя доступные способы.
Поэтапные релизы — Используя поэтапные выпуски, вы можете медленно выкатить сборку в прод, начиная с маленького количества активных пользователей
Однако даже в случае поэтапных выпусков невозможно полностью отозвать сборку: после того, как сборка установлена на устройстве пользователя, единственным способом изменить эту сборку является распространение новой с обновленным номером версии / билда.
Как и в случае поэтапных выпусков, сборки App Store и TestFlight можно обновлять, только выполнив следующие действия:
- Вернитесь в своей системе контроля версий в состояние, к которому вы хотите выполнить откат
- Увеличьте версию и / или номер сборки вашего проекта
- Создайте и подпишите ваше приложение
- Распространите свое приложение через службу бета-тестирования или App Store
- Пользователь должен обновить приложение на своем телефоне.
Вышеуказанные шаги могут быть выполнены вручную, однако рекомендуется полностью автоматизировать процесс, чтобы иметь возможность быстро реагировать.
Альтернатива: “пере-подписать” старую сборку
- Получить доступ к старой сборке (.ipa file) до того, как регрессия была введена
- Обновите версию / номер сборки в Info.plist файле
- “Снова подписать” старую сборку
- Распространите его как новую сборку
Однако “подпись” приложений iOS часто создает больше проблем, особенно потому, что инструменты командной строки Xcode не предлагают хорошего способа сделать это.
Хранение данных
Хранение данных и конфигурации в соответствии с рекомендациями Apple имеет решающее значение для жизненного цикла вашего приложения, в частности, когда речь идет о синхронизации iCloud, обновлении до нового телефона и восстановлении телефона из резервной копии.
Обязательно следуйте официальным Apple iOS Data Storage Guidelines:
Documents: Используйте эту директорию для пользовательского контента, он будет заархивированCaches: Используйте эту директорию для данных, которые могут быть восстановленыtmp: Используйте эту директорию для временных файлов- Используйте
do not back upсвойство для файлов
Никогда не храните конфиденциальную информацию пользователя (например, пароли или сеансы) в этих директориях. Вместо этого используйте Keychain API.
