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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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