Как реализовать ограниченный набор функций (независимость от языка) для ваших пользователей?

Question

Я хотел бы узнать некоторые распространенные или лучшие практики развертывания новой функции веб-сайта для выбранной группы пользователей.

Пользователи могут, например, основываться исключительно на проценте от общей базы пользователей (10%). Развертывание должно быть настраиваемым (настраиваемым) и поддерживать любое количество функций. Также было бы полезно связать развертывание с конкретными ролями или привилегиями пользователя (ACL).

Итак, по сути, что такое архитектура, которая будет достаточно хорошо масштабироваться?

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

Приветствуются ссылки на любые примеры или учебные пособия.

Answer 1

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

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

После завершения развертывания ветвь объединяется, и все видят новую функцию.

Таким образом, вам не нужно беспокоиться о том, что кодовая база, которую видят публичные пользователи бета-версии, отличается (каким-то образом может что-то сломать) от возможной версии кодовой базы.

Answer 2

На моей последней работе мы выполнили это с помощью балансировщика нагрузки и текущей версии cookie.

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

Эта установка не поддерживает обратно несовместимые изменения базы данных. Практически не существует способа сделать это, когда вы можете иметь часть своих пользователей в одной схеме БД и часть в другой, и иметь возможность записывать обе записи, а затем каким-то образом объединять эти записи после того, как вы решили, что новая версия в порядке , Я имею в виду, что это возможно, но на самом деле это зависит от того, какие именно изменения схемы и как они влияют на ваше приложение, поэтому вы не можете сделать это надежным, независимым способом при развертывании. Для нас мы просто старались не делать обратно несовместимых изменений схемы. Если бы нам действительно это было нужно, мы бы попытались отложить деструктивную часть (удаление столбца или таблицы) до более поздней ревизии, где мы могли бы перенести схему и запустить обе версии, не оказывая негативного влияния на текущих пользователей.

Answer 3

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

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

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

Разработка использует GIT для мониторинга версий, и пользователи никогда не видят этого, поскольку мы получаем все виды странных и замечательных экспериментов, загруженных для игры. Он также использует свою собственную базу данных против живых данных.

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

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

Надеюсь, это полезно для вас ... удачи с вашим помощником по тестированию.

Answer 4

Оптимизатор веб-сайта Google кажется именно тем, что вы ищете.