Бета-тестирование новых функций веб-сайта с реальными данными и реальными клиентами

Основная цель этого вопроса – определить подводные камни, связанные с развертыванием слегка измененной версии веб-сайта вместе с работающим веб-сайтом.

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

Конечная цель — позволить определенным клиентам тестировать наши новые функции на своих данных.

So:

  1. Им не нужно делать что-то дважды, переходя на скопированную версию сайта.
  2. Они используют знакомые наборы данных

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

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

Контролируемая версия Git, рабочий процесс Capistrano Deployment, структура Cakephp, MySql В настоящее время у нас есть локальные и тестовые серверы, которые отделены от наших рабочих серверов.

ИЗМЕНИТЬ 20 декабря 2012 г., 10:30 по восточному поясному времени

Основываясь на некоторых комментариях и одном ответе, у меня есть обновление, основанное на отзывах.

  1. Тщательное внутреннее тестирование должно быть проведено перед «бета-тестированием» / тестированием отзывов пользователей. (что мы уже делаем)
  2. Если мы примем эти меры предосторожности и кодовая база покажется надежной, риск развертывания вместе с производственным сервером может быть управляемым. Здесь мы работаем в рамках фреймворка, поэтому вероятность массового удаления и плохого sql относительно низка.

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


person styks    schedule 20.12.2012    source источник
comment
Если это все еще бета-версия кода, существует вероятность потери данных из-за еще не полностью протестированного кода. Быть в одной базе данных для этого может быть проблемой.   -  person Dave    schedule 20.12.2012
comment
Бета-код определенно не должен работать в производственной базе данных. Это может работать нормально, но это может привести к беспорядку в вашей базе данных, когда вы не сможете вернуться, как только ваши клиенты решат, что им не нравятся/нужны функции. Сказав это, если вы изменили в основном пользовательский интерфейс, а базовая функциональность такая же, я думаю, возможно, вы даже могли бы это осуществить.   -  person Ivan Pintar    schedule 20.12.2012
comment
Если вы хотите, чтобы ваши бета-тестеры делали обновления в действующей базе данных, вы могли бы подумать о некоторой репликации данных, но ИМХО это не очень хорошая идея.   -  person icebreaker    schedule 20.12.2012
comment
А как насчет таких сайтов, как Google, где они позволяют бета-тестерам использовать свой новый интерфейс? Я помню, когда выпускалась новая аналитика, я мог довольно легко переключаться между ними. У них должны были быть некоторые различия в БД... Есть идеи, как они этого добились?   -  person styks    schedule 20.12.2012
comment
У вас все еще должны быть Dev, Demo/Testing и Live Server. Даже функции Google Labs должны были пройти серьезное внутреннее тестирование, прежде чем они были включены. При этом у вас все еще может быть бета-интерфейс, который взаимодействует с той же базой данных, но только после того, как он прошел другие циклы тестирования.   -  person Colby Guyer    schedule 20.12.2012
comment
Как я упоминал в вопросе, у нас уже есть локальные и тестовые серверы, которые проходят контроль качества, но мы хотим протестировать некоторые из этих изменений с подмножеством наших пользователей, прежде чем сделать их доступными для всех.   -  person styks    schedule 20.12.2012


Ответы (1)


По-разному...

Если это бета-версия для получения отзывов клиентов о продукте, который был полностью протестирован и, как известно, стабилен, риски относительно управляемы (хотя см. пункты ниже). Это то, как Google определяет «бета».

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

Еще один вопрос, который следует учитывать, заключается в том, является ли база данных обратной и прямой совместимостью между версиями — можете ли вы перевести своих пользователей бета-версии обратно на основную версию, если им не понравится обновление или если что-то пойдет не так? Это гораздо важнее, если, конечно, «бета» означает «непроверенный».

В общем, гораздо проще иметь дело с односторонней совместимостью — позволяя пользователям обновляться, но не откатывать назад — еще один веский аргумент в пользу того, что «бета» означает «отзывы пользователей»…

person Neville Kuyt    schedule 20.12.2012
comment
Это больше похоже на то, чего мы пытаемся достичь. Мы проводим собственное внутреннее тестирование и можем убедиться, что все работает в наших тестовых средах, но нам нужны реальные пользователи, которые выскажут свое мнение. - person styks; 20.12.2012