Каква е реалната цена на preview средите
Цената на preview средите расте с броя на отворените pull request-и, а не с размера на екипа. Разберете къде се крият разходите, кои части могат да се споделят и как да зададете изтичане на preview средите, така че пет отворени PR-а да не означават пет отделни stack-а.
Preview средите са едно от нещата с най-голям ефект, които един екип може да включи. Reviewer-ът отваря link и използва промяната, вместо да чете diff и да си представя как работи тя. Design проблемите се откриват преди merge. QA вече не е отделна фаза.
Те обаче са и разходната позиция, която най-лесно може тихомълком да утрои сметката ви — причината е проста аритметика, която никой не прави в момента, в който включва функционалността.
Аритметиката
Цената на preview средата се определя от броя на отворените pull request-и, а не от броя на хората в екипа или от броя на merge-овете.
Екип от четирима души със здрава review култура може да има между пет и осем отворени PR-а във всеки момент. Ако всеки от тях provision-ва пълно копие на stack-а ви, работите с пет до осем копия на production наред с production средата. Stack, който струва $30 месечно, вече струва $180–$270, а това не е присъствало в ничия оценка, защото оценката е била за една среда.
Още по-лошото е, че отворените PR-и обикновено се натрупват именно когато най-малко можете да си позволите изненади: преди release, по време на refactor, когато някой е в отпуск и branch-ът му остава отворен за три седмици.
Къде всъщност отиват парите
Не всяка част от preview средата струва еднакво и именно разбирането на разликите прави разходите контролируеми.
Application containers — умерен разход и напълно оправдан. Това е частта, която действително ви е нужна. Тя също се мащабира надолу добре, защото preview средата няма нужда от паметта на production.
Бази данни — скъпата част. Отделна база данни за всеки preview е най-големият разход и обикновено е най-малко необходима. Повечето review-и не се нуждаят от изолирана база данни; нужна им е една база с реалистични данни.
Build минути — невидими и натрупващи се. Всеки push към отворен PR стартира нов build. Branch с четиридесет commit-а за две седмици се build-ва четиридесет пъти. Това е реален разход, който никога не се появява като работещ resource, затова изцяло остава извън менталната ви сметка.
Egress — малък за един preview, голям в aggregate. Preview URL-ите биват откривани и crawl-вани. Crawler, който изтегля asset-ите ви от осем preview среди, извършва осем пъти повече работа, отколкото върху production, а вие плащате за всичко това.
Четири неща, които намаляват разходите, без да губите стойността
Споделяйте базата данни
При повечето промени preview средите могат да споделят една база данни, заредена с представителни данни. Запазете изолираните бази данни за PR-ите, които действително имат нужда от тях — migration-и, промени по schema-та и всичко разрушително.
Правилото, което работи на практика: изолирана база данни само когато PR-ът засяга schema-та. Всичко останало се споделя.
Намалете ресурсите на preview средата
Preview среда, която обслужва един reviewer, няма нужда от ресурсите на production. Половината памет и част от CPU обикновено са незабележими за човека, който прави review, но намаляват разходите осезаемо.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Задайте изтичане
Това е промяната с най-голям ефект. Preview средата не трябва да надживява pull request-а си.
Автоматичният teardown при merge или close е минималното необходимо. Това, което създава проблеми на екипите, са изоставените PR-и — branch-ът, който някой е отворил, спрял е да работи по него и никога не е затворил. Тези среди работят с месеци.
Максималната възраст е добрата последна защита: всеки preview, по-стар от например четиринадесет дни, се премахва независимо от състоянието на PR-а. Ако някой отново има нужда от него, това става с една команда.
Не ги допускайте до search engine-ите
Preview URL-ите се индексират. Това е лошо по две причини — duplicate content, който се конкурира с production сайта ви, и crawler traffic, за който плащате в среди, които никой не използва.
dockup noindex my-project/my-api --on
В Dockup PR preview-ите са на ниво 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
Именно изброяването е частта, която екипите пропускат и после съжаляват. Средите, които не можете да enumerate-нете, са среди, за които плащате, без да знаете.
Проверка, която си струва да правите веднъж месечно
Три въпроса за пет минути:
- Колко preview среди работят? Сравнете броя им с броя на реално отворените PR-и.
- На каква възраст е най-старата? Всичко по-старо от две седмици почти сигурно е изоставено.
- Кои имат собствена база данни? Всичко, което не е промяна по schema-та, вероятно няма нужда от отделна база.
Повечето екипи откриват поне една среда от PR, който е бил merge-нат преди месеци, но тя все още работи и продължава да генерира разходи.
Как да получите стойността без неприятни изненади
Нищо от това не е аргумент срещу preview средите. Аргументът е да ги третирате като инфраструктура с lifecycle, а не като checkbox.
Екипите, които правят това правилно, следват три принципа: preview средите се мащабират надолу, изтичат автоматично и споделят всичко, което може да бъде споделено безопасно. Обикновено така целият preview footprint остава под цената на една production услуга — точката, при която ползата очевидно си заслужава.
Екипите, които се изненадват от сметката, са тези, които са включили функционалността веднъж, направили са го правилно и повече никога не са поглеждали списъка.
Често задавани въпроси
Струват ли preview средите колкото production? На ниво отделна среда могат да струват толкова, ако са provision-нати идентично. Когато са с намалени ресурси и споделят база данни, един preview обикновено струва малка част от production.
Трябва ли всеки preview да има собствена база данни? Само когато промяната засяга schema-та. Една споделена база с предварително заредени данни покрива повечето review-и и премахва най-големия разход.
Какво се случва с preview средата, когато PR-ът бъде затворен? Тя трябва да бъде унищожена автоматично. Ако това не се случва, ще натрупате среди от PR-и, които никой вече не помни.
Вредят ли preview средите на SEO?
Могат да навредят, ако бъдат индексирани — duplicate content, който се конкурира с production страниците ви. Маркирайте ги като noindex, което също спира crawler-ите да генерират traffic, за който плащате.