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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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