Сколько на самом деле стоят preview-окружения
Стоимость preview-окружений растёт вместе с числом открытых pull request, а не с размером команды. Узнайте, на что уходят деньги, какие компоненты можно использовать совместно и как автоматически удалять preview-окружения, чтобы пять открытых PR не превращались в пять отдельных стеков.
Preview-окружения — одна из самых эффективных возможностей, которые может включить команда. Ревьюер переходит по ссылке и проверяет изменение вместо того, чтобы читать diff и представлять результат. Дизайн выявляет проблемы ещё до merge. QA перестаёт быть отдельным этапом.
Но это также статья расходов, которая с наибольшей вероятностью незаметно утроит ваш счёт. Причина — в арифметике, которую никто не делает в момент включения этой возможности.
Арифметика
Стоимость preview-окружений зависит от числа открытых pull request, а не от количества людей в команде или числа merge.
В команде из четырёх человек с хорошо налаженным процессом ревью в любой момент может быть открыто от пяти до восьми PR. Если для каждого из них разворачивается полная копия стека, вы запускаете от пяти до восьми копий production параллельно с production. Стек, обслуживание которого стоит $30 в месяц, теперь обходится в $180–$270, и эта сумма не была учтена ни в одной оценке, потому что оценивали стоимость одного окружения.
Хуже того, количество открытых PR растёт именно в моменты, когда меньше всего хочется сюрпризов: перед релизом, во время рефакторинга, когда кто-то в отпуске, а его ветка остаётся открытой на три недели.
На что на самом деле уходят деньги
Не все компоненты preview-окружения стоят одинаково. Понимание различий позволяет контролировать расходы.
Контейнеры приложения — умеренные расходы, которые оправданы. Именно этот компонент вам действительно нужен. Кроме того, его легко масштабировать вниз: preview-окружению не требуется столько памяти, сколько production.
Базы данных — самая дорогая часть. Отдельная база данных для каждого preview-окружения — крупнейшая статья расходов и обычно наименее необходимая. Для большинства ревью не нужна изолированная база; нужна любая база с реалистичными данными.
Build minutes — незаметные и накапливающиеся расходы. Каждый push в открытый PR запускает новую сборку. Ветка с сорока коммитами за две недели будет собрана сорок раз. Это реальные расходы, которые не отображаются как запущенный ресурс, поэтому полностью ускользают от мысленной проверки.
Egress — небольшие расходы на одно preview, но значительные в сумме. Preview URL обнаруживаются и индексируются. Если crawler загружает ваши assets из восьми preview-окружений, он выполняет в восемь раз больше работы, чем при обращении к production, а платите за всё это вы.
Четыре способа сократить расходы без потери пользы
Используйте общую базу данных
Для большинства изменений preview-окружения могут использовать одну базу данных с заранее загруженными репрезентативными данными. Выделенные базы стоит оставлять для PR, которым они действительно нужны: миграций, изменений схемы и любых деструктивных операций.
Практическое правило: изолированная база данных нужна только тогда, когда PR затрагивает схему. Всё остальное можно размещать в общей базе.
Уменьшите масштаб preview-окружения
Preview-окружению, которым пользуется один ревьюер, не нужны ресурсы production. Вдвое меньше памяти и лишь малая доля CPU обычно незаметны для ревьюера, но существенно снижают стоимость.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Удаляйте их автоматически
Это изменение даёт самый заметный эффект. Preview-окружение не должно переживать свой pull request.
Автоматическое удаление после merge или закрытия PR — обязательный минимум. Но команды чаще всего забывают про заброшенные PR: ветку кто-то открыл, затем переключился на другие задачи и так и не закрыл. Такие окружения работают месяцами.
Полезно задать максимальный срок жизни: например, удалять любое preview-окружение старше четырнадцати дней независимо от состояния PR. Если оно снова понадобится, его можно восстановить одной командой.
Исключите их из поиска
Preview URL индексируются. Это плохо по двум причинам: дублирующий контент конкурирует с вашим production-сайтом, а crawler создаёт трафик, за который вы платите, хотя никто не использует эти окружения.
dockup noindex my-project/my-api --on
В Dockup preview для PR настраиваются отдельно для каждого сервиса. Их можно явно включать и отключать, вместо того чтобы наследовать глобальную настройку:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
Именно этап со списком окружений команды часто пропускают, а потом об этом жалеют. Окружения, которые невозможно перечислить, — это окружения, за которые вы платите, даже не подозревая об этом.
Проверка, которую стоит проводить раз в месяц
Три вопроса, пять минут:
- Сколько preview-окружений запущено? Сравните это число с количеством действительно открытых PR.
- Сколько лет самому старому окружению? Всё, что работает дольше двух недель, почти наверняка заброшено.
- У каких окружений есть собственная база данных? Если изменение не затрагивает схему, отдельная база, скорее всего, не нужна.
Большинство команд находят как минимум одно окружение от PR, который был смержен несколько месяцев назад, но оно всё ещё работает и продолжает увеличивать счёт.
Как получить пользу без неожиданных расходов
Всё это не аргумент против preview-окружений. Это аргумент в пользу того, чтобы воспринимать их как инфраструктуру с жизненным циклом, а не как переключатель, который достаточно однажды включить.
Команды, которые правильно организуют этот процесс, делают три вещи: уменьшают масштаб preview-окружений, автоматически удаляют их и используют общие ресурсы там, где это безопасно. Обычно это позволяет удерживать всю инфраструктуру preview дешевле одного production-сервиса — то есть на уровне, при котором её польза очевидно оправдывает затраты.
Команды, которых расходы застают врасплох, однажды включили эту возможность, всё настроили правильно — и больше никогда не смотрели на список окружений.
Часто задаваемые вопросы
Preview-окружения стоят столько же, сколько production? Для одного окружения — могут, если оно развёрнуто идентично production. При уменьшенном масштабе и общей базе данных preview обычно обходится лишь в долю стоимости production.
Должно ли у каждого preview быть собственное окружение? Только если изменение затрагивает схему. Одной общей базы с заранее загруженными данными достаточно для большинства ревью, а крупнейшая статья расходов исчезает.
Что происходит с preview после закрытия PR? Оно должно удаляться автоматически. Если этого не происходит, постепенно накапливаются окружения от PR, о которых уже никто не помнит.
Вредят ли preview-окружения SEO?
Могут, если их проиндексируют: дублирующий контент начнёт конкурировать со страницами production. Добавьте им noindex — это также остановит crawler, который создаёт платный для вас трафик.