Как мне предложить бета-функцию для выбора пользователей?(рельсы)

Question

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

Некоторые проблемы, к которым я не могу придумать решения:

• Бета-функция может потребовать переноса базы данных.Как вы можете справиться с этим, если это может вызвать проблемы с существующим приложением?
• Изменение шаблонов и css / sass, вероятно, также изменит его для существующих функций.
• Изменение базового кода модели может привести к поломкесуществующие контроллеры / интерфейсы, которые полагаются на него.

Одним из решений (плохой вариант) является кодирование новой функции и ее оборачивание в логику, которая показывает / использует ее, только если у пользователя есть «бета»роль.Проблема в том, что когда вы, наконец, выйдете вживую, у вас может быть много чего сделать.Это пустая трата времени и может привести к ошибкам.

Другое решение состоит в том, чтобы запустить отдельную ветку «бета» приложения с субдомена и направить к нему пользователей с бета-ролью.Проблема заключается в том, что сложность ssl-сертификатов, ссылок электронной почты и других проблем, зависящих от домена, делает это немного трудной задачей обслуживания (хотя и не такой плохой, как первое решение).

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

Answer 1

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

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

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

Для функций просто используйте разные ветви для этих новых функций и создайте «промежуточную» среду из этой ветви, после того, как функции будут протестированы, вы просто объедините их с HEAD, и новая функция появится:]

Answer 2

Одна вещь, о которой я думаю, это настройка бета-версии «промежуточной» среды, которая на самом деле является производственной средой.Идея состояла бы в том, чтобы создать beta.mydomain.com, а затем отправлять туда пользователей, которые хотят получить функции раньше.По сути, это будет просто ветвь, которая будет развернута на бета-сайте, который работает.

Answer 3

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

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

Одним из возможных способов обслуживания нескольких версий вашего приложения является использование альтернативного формата response_to для вашего бета-сайта. Вы можете создать метод в вашем ApplicationController, чтобы проверить, был ли пользователь в бета-версии. Если true, вы можете переопределить значение request.format, и в вашем блоке response_to есть ответ типа "format.beta".

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

(Кстати, похоже, у нас очень похожие имена! :-))

Answer 4

Лично я не считаю плохой идеей заключать код в чек для пользователя с бета-ролью. Будет достаточно легко найти все вызовы, например, if current_user.authorized?(:beta) и полностью удалить их.

Answer 5

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

Для этого я предполагаю

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

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

Когда вы переходите на полную версию, просто обновляйте бета-пользователей как обычные пользователи

Я не знаю, как это применимо кваш сценарий

спасибо

Самера