Окружения, стенды и доставка кода

«Не воспроизводится» одна из самых частых фраз при разборе ошибок. Покупатель видит проблему на рабочем сайте, а у разработчика на своём компьютере всё работает. Часто дело не в том, что ошибки нет, а в том, что у них разные копии одного приложения с разными данными, настройками и правами. Разберём, какие бывают такие копии, откуда в них данные и как выбрать подходящую для проверки.

Кейс: письмо приходит только на тестовом сайте

Покупатели «Узелка» жалуются: после заказа не приходит письмо с подтверждением. Тестировщик оформляет заказ на тестовом сайте, письмо приходит, и ошибка «не воспроизводится». Разработчик проверяет код: тот же самый, что на рабочем сайте. Причина нашлась не в коде. На тестовом сайте письма уходят в специальный почтовый ящик-ловушку, а на рабочем стоят настройки настоящего почтового сервиса, и в них указан адрес отправителя, который сервис не принимает.

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

Какие бывают окружения

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

Окружение	Для чего	Данные	Кто имеет доступ	Внешние сервисы
Разработка	Программист пишет и проверяет код	Выдуманные, минимум	Разработчики	Заглушки вместо настоящих сервисов
Тестовое	Тестировщики проверяют работу по требованию	Выдуманные, подготовленные для проверок	Команда: разработчики, тестировщики, аналитики	Заглушки или тестовые версии сервисов
Предпродовое	Репетиция выпуска: всё как на рабочем, но без реальных покупателей	Обезличенные копии рабочих или близкие к ним	Узкий круг команды	Тестовый режим настоящих сервисов
Рабочее	Сайт, которым пользуются покупатели	Реальные: заказы и покупатели	Строго ограничен: права выдают по необходимости	Настоящие: банк, почта, SMS

Заглушка это программа, которая изображает чужой сервис: «банк» из заглушки всегда отвечает «оплачено», и деньги не списываются. Именно поэтому заказ на тестовом сайте может пройти там, где на рабочем он не проходит.

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

Откуда берутся данные на стендах

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

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

Как код попадает на окружение

Код сначала пишут на компьютере разработчика. Чтобы он заработал в окружении, его собирают: превращают текст программы в готовый к запуску набор файлов, а затем разворачивают: выкладывают на нужное окружение. Эти шаги можно делать вручную, но обычно их автоматизируют цепочкой CI/CD: при каждом изменении она сама собирает программу, запускает автоматические проверки и выкладывает на тестовое окружение. На рабочее окружение одни команды выкладывают тоже автоматически, другие после ручного решения. Как устроены серверы и контейнеры, на которых всё это запускается, разбирает статья 06-04.

Как выбрать окружение для воспроизведения ошибки

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

1. Выяснить, где ошибка видна: только на рабочем сайте или и на тестовом.
2. Если и на тестовом: воспроизводить там. Нужны учётная запись тестового покупателя и данные, как в жалобе, чтобы повторить те же шаги.
3. Если только на рабочем: искать отличия между окружениями: данные, настройки, подключённые сервисы. В кейсе вышли на настройки почтового сервиса.
4. Если ошибка зависит от объёма или формы реальных данных: попросить предпродовое окружение с обезличенной копией базы.
5. Если ничего не помогло: попросить поддержку или разработчика посмотреть рабочее окружение без действий, только на чтение. Права на рабочее окружение часто есть только у поддержки и у нескольких разработчиков.

«Не воспроизводится» не значит «ошибки нет». Это значит «на этом окружении не выполнены условия»: нужные данные, настройки или права. Чтобы не гадать, в заявке на разбор пишут, на каком окружении ошибку видели, с какими данными и какими шагами.

Где это встречается в работе

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

Итог

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

Что дальше

• 01-06. От идеи до релиза: жизненный цикл разработки и путь задачи
• 05-31. Как разбирать ошибку: от жалобы пользователя до причины
• 06-04. Инфраструктура: сервер, контейнер, облако
• 02-25. От требований к тестированию: тест-кейсы и приёмка

Источники

• Continuous integration vs. delivery vs. deployment, Atlassian. Цепочка сборки, проверок и выкладки на тестовое и рабочее окружения.
• Environments, GitLab Docs. Окружение как цель развёртывания: dev, staging, production.