При создании DevCycle мы создали правило таргетинга show add, которое позволяет пользователю определять несколько аудиторий, на которые можно ориентироваться в любой среде, которую они определили для своего приложения.

В исходном состоянии в DevCycle пользователи могли определить только одно правило для целевых пользователей. Например, можно настроить фильтр, чтобы только пользователи в Канаде могли видеть определенный вариант функции. Затем они могут включить или отключить эту функцию, чтобы только люди в Канаде видели синюю версию, а не зеленую. Множественные правила таргетинга позволяют пользователю определять целевую аудиторию, чтобы иметь более детальный таргетинг. Допустим, вы хотели предоставить определенную версию функции канадцам, использующим устройства Android, и какую-то другую версию — канадцам, использующим устройства iOS. Вы можете легко добавить правило таргетинга, которое будет иметь другое определение.

Для этого в пользовательский интерфейс и API DevCycle была добавлена ​​возможность легко «добавить» правило таргетинга.

Как мы использовали флаги функций

При создании этой функции у нас было правило добавления таргетинга за флагом функции, пока мы не были уверены, что и наши API, и интерфейсный интерфейс правильно отображают сохраненные данные для создания новых правил и отправки их на серверную часть.

Мы хотели убедиться, что сможем протестировать продукт в производственной среде, прежде чем мы представим его всем нашим клиентам и заказчикам. Сначала мы поместили его за флагом функции, включив его только для наших внутренних пользователей, а затем мы развернули его для всех.

При создании новой функции приоритетом для нашей команды было убедиться, что приложение не перестанет работать так, как должно. Главной заботой было обеспечение того, чтобы у пользователя приложения был отличный опыт.

Мы использовали флаги функций для создания правила таргетинга, которое по своей сути требовало таргетинга для работы. Изначально мы допускали определение одной аудитории, и это было все, что мог сделать пользователь. Это позволило каждому установить флаг базовой функции. Оттуда мы расширились, чтобы обеспечить дополнительные уровни настройки.

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

Одна из приятных вещей при создании с флагами функций заключается в том, что мы можем тестировать как в нашей среде разработки, так и в тестовой среде. У нас была предварительная версия в реальном времени, связанная с производственным API, которую мы смогли протестировать, прежде чем развернуть пользовательский интерфейс в рабочей среде. Поскольку он был завернут в флаг функции, если что-то принципиально сломалось, мы могли легко откатить его, чтобы все начали видеть вариант по умолчанию или базовый вариант. Это позволяет приложению продолжать работу, пока команда инженеров исправит любые ошибки.

Поскольку у нас работают разные версии как нашего клиента, так и нашего API, эти варианты не всегда так точно синхронизированы, как мы думаем. Было несколько случаев, когда мы вносили изменения в API, которые интерфейс не был готов обработать.

Использование флагов функций свело к минимуму простои в производстве и позволило нашим внутренним командам проводить контроль качества и тестировать новые функции до того, как они будут запущены. Это помогает нам выявлять ошибки до того, как клиенту нужно будет поднять тикет или пожаловаться нашей команде, что значительно упрощает нашу жизнь.

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

Использование флагов функций похоже на обучение езде на велосипеде. В первый раз у вас может быть несколько промахов и падений, но как только вы освоитесь, вы никогда не забудете, как их использовать.

На что было бы похоже создание без флагов функций

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

С флагами функций мы протестировали все в нашей среде разработки и подготовки к производству, а затем одним нажатием кнопки мы могли запуститься. Если бы мы не использовали флаги функций, это пришлось бы делать в нерабочее время. Без флагов функций развертывание любого приложения обычно начинается около 22:00, даже если это небольшой внутренний выпуск приложения, и окно для развертывания может длиться до 6:00. Это означает, что тот, кто отвечает за выход в эфир, должен не ложиться спать и ждать, пока он не получит подтверждение и не проведет первоначальный дымовой тест, прежде чем подписать на ночь. Другая проблема заключается в том, что если что-то пойдет не так и вы не используете флаги функций, вам придется откатывать все развертывание. Это означает, что вы потратили впустую целую ночь, потому что обнаружили ошибку или что-то еще в процессе развертывания, которое прошло неправильно.

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

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

Как флаги функций помогают крупным организациям

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

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

Начните использовать DevCycle

Избегайте поломки вашей сборки. Флаги функций экономят время разработчиков, снижают риск и связанный с этим стресс. Начните использовать флаги функций с 14-дневной бесплатной пробной версией DevCycle.