Любой товар, который сейчас находится в магазине, находится под угрозой выпуска.
Наш проект не является исключением.
Мы работаем по методологии Scrum, разработка разбивается на спринты, обычно спринты не привязаны ко времени, а делятся на временные периоды в зависимости от объёма спринта.
В конце спринта приложение обычно выпускается в магазин и включает в себя новые функции и исправления некоторых ошибок.
Однако из-за специфики проекта не все функции выпускаются сразу по окончании спринта.
Из-за такого подхода появляются фичи, которые невозможно выпустить в производство.
При этом никто не отменял критические ошибки, мелкие исправления и просто выпуск готовых функций.
Существует несколько типов выпусков:
- Итеративная разработка.
Выпуск готовых и утвержденных функций.
- Различные сроки принятия функций.
Каждая функция имеет разный приоритет со стороны заказчика, что определенно влияет на время выпуска даже готовых функций.
- Критические ошибки и соглашения об уровне обслуживания.
Если в промышленных сборках обнаружены реальные проблемы, необходимо как можно скорее исправить ошибку и выкатить обновление.
Первоначально в Серфинг Подход «фича-ветви» был организован, давайте рассмотрим его концепцию, выделим плюсы и минусы.
Идея этого подхода максимально проста.
Каждый раз, когда разработчик начинает работать над новой функцией, он создает для нее отдельную FeatureBranch, что позволяет ему абстрагироваться от текущей DevBranch. Таким образом, разработчик уходит со своей фичей в отдельный мир, не обращает внимания на то, что происходит в основной ветке, файлит фичу в отдельную ветку и отправляет все подзадачи в FeatureBranch своей фичи.
После успешного завершения всей фичи разработчик успешно пытается объединить свой готовый код с основной веткой разработки, чтобы впоследствии сделать релиз.
Но это было не так, со 100% вероятностью, если бы он выполнял свою задачу достаточно долго, у него были бы конфликты.
И очень хорошо, если эти конфликты есть только в каких-то Swift-файлах, но часто, если фича долго томилась в этой ветке, проходя все этапы согласования, тестирования и отладки, то конфликты начинают проявляться и в xib-файлах, и такие конфликты доставляют массу удовольствия в момент их исправления.
На этом экране сразу появляется воздействие, и время слияния мгновенно увеличивается.
Какие преимущества можно выделить в этом подходе?
- Эта функция абстрагирована от остального кода.
- Работа не блокируется релизами.
- Нежелательный код не может попасть в производство.
- Сложность поддержки крупных веток в случае задержки релиза.
- Постоянные конфликты на работе.
- Отличный эффект при слиянии.
- Нет возможности быстро собрать сборку сразу с несколькими функциями.
FeatureToggle
Мы не придумали ничего нового в этом подходе, мы просто использовали его в нужное время и в нужном месте.Часто FeatureToggle используется в приложениях для проведения A/B-тестирования или включения/выключения различных функций в зависимости от настроек на сервере.
Мы начали использовать этот подход локально для решения своих проблем при работе с филиалами.
Суть этого подхода в том, что больше нет необходимости поддерживать отдельные ветки для каждой фичи.
Сейчас, на этапе проектирования и декомпозиции задачи, решается, как мы будем ее проводить.
Если мы понимаем, что эту функцию можно легко скрыть за каким-то флажком, то больше никаких «ветвей функций» не используем.
Это работает следующим образом:
В нашем приложении есть небольшой класс, содержащий статические изменяемые переменные.public final class FeatureToggle { public enum SomeFeature { public static var isEnabled = true public static var useMocks = false } }
Каждый из них отвечает за доступность того или иного функционала в приложении.
Таким образом, каждый разработчик может развиваться в текущей ветке dev, т.е.
все его задачи сливаются в текущую ветку dev, а работа и релизы другого функционала не блокируются тем, что эта задача еще не завершена.
Использование этих флагов выглядит даже проще, чем вы думаете.
Поскольку все это происходит локально, нам не нужно получать какие-либо настройки с сервера.
if FeatureToggle.SomeFeature.isEnabled {
// Should show feature
} else {
// Should hide feature
}
А для того, чтобы любой желающий мог иметь доступ к скрытому функционалу, мы реализовали простой экран, на котором его можно включить «на горячее».
выводы
Мы должны понимать, что этот подход не является панацеей.Не каждое изменение можно скрыть FeatureToggle .
Например, добавляя кеш в наше приложение, мы понимали, что скрыть такое большое влияние невозможно; кэш затронул практически всю функциональность приложения.
В данном случае мы использовали для этой задачи отдельную ветку и, конечно же, получили огромное количество конфликтов на выходе.
Но зачастую почти любая новая функциональность, которую мы добавляем в приложение, может быть скрыта за простыми флагами, которые упрощают разработку, тестирование и выпуск.
Из минусов:
- Не все изменения можно скрыть за FeatureToggle.
- Вы должны понимать, что, хотя и скрытые, функциональные возможности могут влиять на некоторые части приложения.
- Больше нет необходимости поддерживать большие ветки функций.
- Количество конфликтов уменьшилось.
- Релизы ускорились.
- Теперь вы можете быстро скрыть и раскрыть нужный вам функционал.
- Больше нет необходимости пересобирать проект для тестирования давно забытого функционала приложения.
Каков результат?
Цель этой серии статей — не просто поделиться тем или иным подходом с большой аудиторией, я хотел приоткрыть завесу над разработкой мобильных приложений.Статей о разных подходах по отдельности довольно много, но редко кто говорит о темной стороне разработки, которая скрыта от глаз.
Спустя полтора года разработки банковского приложения мы поняли, что невозможно сразу реализовать идеальный проект. Разработка крупного банковского приложения — задача, с которой справится не каждый.
В каждом спринте мы сталкивались с новыми проблемами и решали их теми способами, которые казались нам наиболее эффективными.
Не все решения сработали, поэтому я постарался собрать только полезные выводы, которые сработали для нас.
Вот список тем, которые мы обсуждали в этой серии статей:
- Проблемы архитектуры в крупных проектах
- Проблемы взаимодействия с внешними командами на крупных проектах
- Проблемы с инструментами в крупных проектах
- Проблемы с доставкой функций в крупных проектах
Все решения и подходы были получены только благодаря мотивации каждого члена команды сделать продукт лучше и жизнь других немного проще.
Теги: #разработка iOS #git #разработка мобильных приложений #Swift #переключение функций
-
Spider — Новая Платформа Amd
19 Oct, 24 -
Асинхронные Задачи В C++11
19 Oct, 24
