Как внедрить ограниченный набор функций (независимость от языка) для ваших пользователей?
Я хотел бы узнать некоторые распространенные или лучшие практики развертывания новой функции веб-сайта для выбранной группы пользователей.
Например, пользователи могут быть основаны исключительно на проценте от общей пользовательской базы (10%). Развертывание должно быть настраиваемым (настраиваемым) и поддерживать любое количество функций. Также было бы полезно связать развертывание с определенными ролями или привилегиями пользователя (ACL).
Итак, по сути, что такое архитектура, которая будет достаточно хорошо масштабироваться?
Что касается языковой части, не связанной с языком, вы можете предоставить псевдокод, общие концепции или идеи или фрагменты из предпочитаемого вами языка, чтобы донести свою мысль.
Ссылки на любые примеры или учебники приветствуются.
4 ответа
Я рекомендую, чтобы для людей, получающих новую функцию, сайт, на котором они работают, был как можно ближе к сайту, на котором все будут находиться, как только эта функция станет общедоступной.
Другими словами, у меня не было бы, например, условной логики на странице, чтобы определить, должна ли кнопка быть видимой или нет, если бы это условие существовало только в течение этого периода бета-тестирования. Скорее, я бы определил во время входа в систему, является ли этот человек бета-участником или нет (это определение может быть случайным, может ссылаться на его роль и т. Д.). Если они являются участниками, они будут перенаправлены на отдельно развернутый сайт, развернутый из ветви управления версиями.
После завершения развертывания ветка объединяется, и все видят новую функцию.
Таким образом, вам не нужно беспокоиться о том, что кодовая база, которую видят публичные пользователи бета-версии, отличается (каким-то образом может что-то сломать) от возможной версии кодовой базы.
На моей последней работе мы выполнили это с помощью балансировщика нагрузки и текущей версии cookie.
Балансировщик нагрузки установил cookie, идентифицирующий номер редакции экземпляра, который использовал пользователь. Если этот файл cookie уже присутствует, балансировщик нагрузки просто отправит этот запрос работающему экземпляру с соответствующей ревизией. Когда мы развернули новую ревизию, балансировщик нагрузки продолжал отправлять трафик с существующим файлом cookie ревизии в их исходную ревизию до тех пор, пока эта ревизия не перестала работать или пользователь не закрыл свой браузер. Новый трафик будет отправлен во вновь развернутую ревизию. Это позволило нам немного протестировать изменения, в то время как наши существующие пользователи продолжали использовать старую версию. Мы также могли бы вручную установить этот файл cookie для проверки новой версии внутри рабочей среды, прежде чем включить на нее новый трафик. Когда мы почувствовали, что у новой ревизии нет серьезных проблем, мы могли бы снять старую ревизию, и весь трафик начал переходить на последнюю ревизию.
Эта настройка не поддерживает обратно несовместимые изменения базы данных. Практически не существует способа сделать это, когда вы можете иметь часть своих пользователей в одной схеме БД и часть в другой, и иметь возможность записывать обе записи, а затем каким-то образом объединять эти записи после того, как вы решили, что новая версия в порядке, Я имею в виду, что это возможно, но это действительно зависит от того, какие именно изменения схемы и как они влияют на ваше приложение, поэтому вы не можете сделать это надежным, независимым способом при развертывании. Для нас мы просто старались не делать обратно несовместимых изменений схемы. Если бы нам действительно это было нужно, мы бы попытались отложить деструктивную часть (удаление столбца или таблицы) до более поздней ревизии, где мы могли бы перенести схему и запустить обе версии, не оказывая негативного влияния на текущих пользователей.
Для процесса случайного выбора мне нравится концепция запроса каждого клиента, когда у него будет успешный вход, хотят ли они участвовать в бета-тестировании, когда будет достигнуто требуемое или требуемое количество пользователей, вы перестанете спрашивать. В базе данных я склонен хранить данные о том, на какой сервер перенаправлять пользователя, и запускать стандартный скрипт, который перемещает каждого пользователя в нужное место при входе в систему.
Мы разрабатываем наше приложение за месяцы до разработки и избегаем изменений в существующей схеме. Причина очень очевидна, конечно, это не всегда возможно, поэтому, когда у нас есть подобное изменение, мы всегда полностью документируем это изменение, когда оно написано, и планируем миграцию для этого поля как можно раньше. Таким образом, у нас есть план сражения о том, какие изменения вносятся, и мы можем найти лучшее решение, которое только возможно для нас. К сожалению, это меняется в зависимости от обстоятельств.
Мы всегда используем несколько сред, у нас есть производство, разработка и бета-версия в целом. Это означает, что мы не вмешиваемся в производственные сервисы, которые равняются деньгам, у нас нет людей, которые нарушают код и отключают сервис при оптимизации.
Разработка использует GIT для мониторинга версий, и пользователи никогда не видят этого, так как мы загружаем всевозможные странные и замечательные эксперименты для игры. Он также использует свою собственную базу данных против живых данных.
С бета-версией мы переносим конкретные пользовательские данные в целом, но недавно у нас появился лучший опыт дублирования всей базы данных и планирования конкретной даты начала бета-тестирования. Это позволяет пользователям отказаться от бета-тестирования, а другие могут выбрать с минимальными изменениями, необходимыми для поддержки этой опции. Как правило, мы выполняем миграцию новых данных между двумя базами данных один раз в день, новые и только вступают в силу только с момента переноса данных на другую платформу.
Мы также добились успеха в небольшом масштабе, используя существующую производственную базу данных для бета-тестирования некоторых новых функций, которые работали из своей собственной таблицы, поэтому в зависимости от того, что вы делаете с данными, использование одной и той же действующей базы данных может быть хорошим вариантом.
Я надеюсь, что это полезно для вас... удачи с вашим помощником по тестированию.
Оптимизатор веб-сайта Google выглядит как раз то, что вы ищете.