Что такое staging-окружение? Копия, которая никогда не бывает копией

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

Идея старая и простая: сначала попробуй там, где это неважно. Интересной её делает то, что staging никогда не бывает настоящей копией, и каждая проблема, которую он не поймал, приходит именно из этого зазора.

Между чем он стоит

Большинство команд приходит к трём или четырём окружениям, и различия между ними - в том, кому позволено их ломать.

• Локальное - это машина разработчика. Оно ломается постоянно, и никто не против.
• Staging выполняет код, который вот-вот уедет, на данных, о которых никто не пожалеет. Он ломается время от времени, и кто-то немного против.
• Продакшен - это там, где клиенты.

Некоторые команды добавляют между staging и продакшеном четвёртое окружение для нагрузочного или интеграционного тестирования, а некоторые ставят перед staging preview-окружение на каждую ветку. Названия расходятся сильнее, чем идеи.

Для чего он нужен

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

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

Давать не-разработчикам место, куда можно посмотреть. Приёмочное тестирование, демонстрация, скриншот для поддержки - всем им нужно что-то настоящее, что не является настоящим.

Как staging расходится с продакшеном

Это та часть, которую стоит записать, потому что staging-окружение, за которым никто не следит, хуже, чем его отсутствие: оно производит уверенность вместо информации.

Расходится код. Всё смерженное уезжает на staging автоматически; продакшен деплоят, когда кто-то так решил. Staging на тридцать коммитов впереди продакшена рассказывает вам о программе, которой у ваших клиентов нет, а баг, который вы не можете воспроизвести на staging, там, возможно, просто уже починен.

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

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

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

Как держать зазор честным

Закрыть зазор нельзя, поэтому цель - знать, где он.

• Деплойте в оба одинаково. Одна команда, один скрипт, никаких ручных шагов, существующих только в одном месте. Если в продакшене есть шаг, которого нет на staging, этот шаг никогда не проверялся.
• Деплойте их вместе, когда изменение затрагивает оба. Всё, у чего есть клиент - расширение для браузера, мобильное приложение, партнёрская интеграция, - что разговаривает с одним окружением и не разговаривает с другим, для тестировщика не выкачено ни в одном из них.
• Используйте данные формы продакшена, а не данные продакшена. Обезличенные или сгенерированные, с намеренно включёнными неудобными формами: пустая учётная запись, огромный список, апостроф. Копирование живых клиентских данных в менее защищённое окружение - это инцидент с приватностью, который ждёт своей даты.
• Держите его выключенным, когда он не нужен, и рассчитывайте на то, что он мишень: staging-окружения славятся тем, что пропатчены хуже и открыты шире, чем системы, которые они зеркалят.
• Говорите, где что. Баннер, цвет, что угодно. Рано или поздно кто-нибудь проведёт демонстрацию на продакшене или разрушительный тест не на том хосте, и предотвращение этого стоит одной строчки CSS.

Когда staging говорит одно, а продакшен другое

Это не провал staging, это та самая информация, ради которой он существует, и это момент выяснить, какое из четырёх расхождений выше объясняет разницу.

Первый вопрос - какой билд выполняется в каждом из них. Второй - происходит ли то же самое на тех же данных. И то и другое отчёт должен сообщать, и того и другого регулярно не хватает во фразе “на staging работает”.

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

Коротко

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