Скільки насправді коштують preview environments
Вартість preview environment зростає разом із кількістю відкритих pull request, а не з розміром команди. Дізнайтеся, куди непомітно йдуть кошти, які частини варто спільно використовувати та як автоматично завершувати previews, щоб п’ять відкритих PR не перетворювалися на п’ять окремих стеків.
Preview environments — одна з найкорисніших можливостей, які може ввімкнути команда. Reviewer переходить за посиланням і взаємодіє зі зміною замість того, щоб читати diff та уявляти результат. Проблеми в дизайні виявляються ще до merge. QA перестає бути окремою фазою.
Водночас це стаття витрат, яка найімовірніше непомітно потроїть ваш рахунок. Причина — проста арифметика, яку ніхто не робить у момент увімкнення цієї можливості.
Арифметика
Вартість preview environment залежить від кількості відкритих pull request, а не від кількості людей у команді чи кількості merge.
У команди з чотирьох людей і здоровою культурою code review у будь-який момент може бути відкрито від п’яти до восьми PR. Якщо для кожного з них розгортати повну копію вашого stack, ви запускаєте від п’яти до восьми копій production паралельно з production. Stack, який коштує $30 на місяць, тепер обходиться в $180–$270. І це не враховано в жодній оцінці, адже оцінювали один environment.
Ще гірше те, що відкриті PR часто накопичуються саме тоді, коли сюрпризи найменш бажані: перед релізом, під час рефакторингу, коли хтось у відпустці, а його branch залишається відкритим на три тижні.
Куди насправді йдуть кошти
Не кожна частина preview коштує однаково. Розуміння цієї різниці дає змогу контролювати витрати.
Application containers — помірні витрати, які виправдані. Це саме та частина, яка вам потрібна. Вона також добре масштабується вниз, адже preview не потребує стільки memory, як production.
Databases — найдорожча частина. Окрема database для кожного preview — найбільше джерело витрат і зазвичай найменш необхідна річ. Для більшості code review не потрібна ізольована database — потрібна якась database із правдоподібними даними.
Build minutes — непомітні та накопичуються. Кожен push до відкритого PR запускає новий build. Branch із сорока commit за два тижні збирається сорок разів. Це реальні витрати, які не відображаються як запущений ресурс, тому повністю випадають із ментального аудиту.
Egress — невеликі витрати для одного preview, але значні в сукупності. Preview URL знаходять і сканують. Crawler, який завантажує ваші assets із восьми preview environments, виконує у вісім разів більше роботи, ніж під час сканування production, а платите за все це ви.
Чотири способи скоротити витрати без втрати переваг
Спільно використовуйте database
Для більшості змін previews можуть спільно використовувати одну database, наповнену репрезентативними даними. Ізольовані databases варто залишити для PR, яким вони справді потрібні: migrations, зміни schema та будь-які destructive-операції.
Правило, яке працює на практиці: ізольована database — лише якщо PR змінює schema. Усе інше можна спільно використовувати.
Зменшуйте ресурси preview
Preview, яким користується один reviewer, не потребує ресурсів production. Удвічі менший обсяг memory і частка CPU зазвичай непомітні для людини, яка перевіряє зміни, зате суттєво зменшують витрати.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Автоматично завершуйте previews
Це зміна з найбільшим ефектом. Preview не має переживати свій pull request.
Automatic teardown після merge або закриття PR — базова вимога. Команди найчастіше забувають про покинуті PR: branch хтось відкрив, потім переключився на іншу задачу й більше не закрив. Такі environments працюють місяцями.
Варто встановити максимальний вік як додатковий захист: будь-який preview, старший, наприклад, за чотирнадцять днів, видаляється незалежно від стану PR. Якщо він знову знадобиться, його можна відновити однією командою.
Виключіть їх із пошуку
Preview URL індексуються. Це погано з двох причин: дубльований контент конкурує з вашим production-сайтом, а crawler traffic створює витрати в environments, якими ніхто не користується.
dockup noindex my-project/my-api --on
У Dockup PR previews налаштовуються для кожного service окремо. Їх можна явно ввімкнути або вимкнути, замість того щоб успадковувати глобальне налаштування:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
Саме перелік previews команди часто пропускають, а потім шкодують. Environments, які неможливо перелічити, — це environments, за які ви платите, навіть не знаючи про них.
Аудит, який варто проводити раз на місяць
Три запитання, п’ять хвилин:
- Скільки previews працює? Порівняйте це число з фактичною кількістю відкритих PR.
- Скільки років найстарішому? Усе, що старше двох тижнів, майже напевно покинуте.
- Які з них мають власну database? Якщо зміна не стосується schema, окрема database, найімовірніше, не потрібна.
Більшість команд знаходить щонайменше один environment із PR, який було злито кілька місяців тому, але він досі працює й генерує витрати.
Як отримати переваги без непередбачених витрат
Усе це не аргумент проти preview environments. Це аргумент на користь того, щоб розглядати їх як інфраструктуру з власним lifecycle, а не як checkbox.
Команди, які правильно організували цей процес, роблять три речі: зменшують ресурси previews, автоматично завершують їх і спільно використовують те, чим можна безпечно ділитися. Зазвичай це дає змогу втримати весь preview footprint дешевшим за один production service — саме за такої ціни переваги очевидно виправдовують витрати.
Команди, які стикаються з неприємними сюрпризами, зазвичай один раз правильно все ввімкнули й більше жодного разу не переглянули список.
Поширені запитання
Чи коштують preview environments стільки ж, скільки production? Для окремого environment — можуть, якщо вони розгортаються ідентично. Якщо зменшити ресурси й спільно використовувати database, preview зазвичай коштує лише частину production.
Чи має кожен preview мати власну database? Лише коли зміна стосується schema. Одна спільна database із початково підготовленими даними покриває більшість code review і усуває найбільше джерело витрат.
Що відбувається з preview після закриття PR? Його слід автоматично знищувати. Якщо цього не робити, накопичуватимуться environments із PR, про які вже ніхто не пам’ятає.
Чи шкодять preview environments SEO?
Можуть, якщо їх індексують: дубльований контент конкурує з вашими production-сторінками. Додайте їм noindex — це також зупинить crawler traffic, за який ви платите.