Любое простое изменение становится сложным, когда приложение уже работает. Ведь на нем находятся активные пользователи, которые, например, оставляют комментарии или покупают товар. Это связано с риском ухудшением пользовательского опыта или поломкой какой-либо части приложения.
Чтобы уменьшить риск, изменение включают для определенной группы или сегмента пользователей для проверки. По результатам успешности принимается решение о включении изменения для всех или удалении изменения. Это называется A/B-тестирование.
Сами тесты можно разделить на простые и сложные.
Сложные - это когда есть большой набор данных, которые используются в условии отображения. Обычно в этом случае проверкой условия занимается отдельный сервис, к которому обращается приложение. Организация таких тестов выходит за рамки статьи.
И простые - это когда условие основано на чем-то простом, например, 50% пользователей должны видеть первый вариант, а остальные - второй. На моей практике применение простых тестов актуально в следующих задачах:
- проверить новый дизайн
- проверить техническое улучшение/изменение: переход на использование другого сервиса, вынос части приложения в отдельное приложение (виджет)
Решение
Чтобы не засорять код приложения проверкой условия, проверку можно делегировать HTTP-серверу, в нашем случае Nginx.
Модуль ngx_http_split_clients_module позволяет определить условие для разделения клиентов (каждый клиент - это отдельный запрос к серверу).
В примере ниже я 50% запросов отправляю на обновленное приложение с версией 2. А остальные видят основную версию.
При необходимости более медленной выкатки (например, чтобы проверить, что после выноса части приложения в отдельное приложение (виджет), оно держит нагрузку) достаточно уменьшить процент.
Чтобы протестировать что версия 2 отображается корректно, я добавил возможность указать версию в Cookie.
Код доступен по ссылке aarefiev/nginx.conf.