Ile naprawdę kosztują środowiska preview
Koszt środowisk preview rośnie wraz z liczbą otwartych pull requestów, a nie z wielkością zespołu. Dowiedz się, gdzie ukrywają się wydatki, które elementy można współdzielić i jak wygaszać środowiska preview, aby pięć otwartych PR-ów nie oznaczało pięciu stacków.
Środowiska preview to jedna z najbardziej opłacalnych rzeczy, jakie zespół może włączyć. Reviewer klika link i korzysta ze zmiany, zamiast czytać diff i wyobrażać sobie efekt. Problemy projektowe wychodzą na jaw przed merge’em. QA przestaje być osobną fazą.
To także pozycja na rachunku, która najłatwiej może po cichu potroić koszty — a powodem jest prosta matematyka, której nikt nie wykonuje w momencie włączania tej funkcji.
Matematyka
Koszt środowiska preview skaluje się wraz z liczbą otwartych pull requestów, a nie z liczbą osób w zespole ani liczbą merge’ów.
Czteroosobowy zespół, który sprawnie prowadzi code review, może mieć w danym momencie otwartych od pięciu do ośmiu PR-ów. Jeśli każdy z nich uruchamia pełną kopię stacku, działacie na pięciu do ośmiu kopiach produkcji równolegle z produkcją. Stack, którego utrzymanie kosztuje 30 USD miesięcznie, zaczyna kosztować 180–270 USD, a żadna z tych kwot nie pojawiła się w żadnym oszacowaniu, bo dotyczyło ono jednego środowiska.
Co gorsza, liczba otwartych PR-ów rośnie właśnie wtedy, gdy najmniej możecie sobie pozwolić na niespodzianki: przed release’em, podczas refaktoryzacji, gdy ktoś jest na urlopie, a jego branch pozostaje otwarty przez trzy tygodnie.
Na co naprawdę idą pieniądze
Nie każda część środowiska preview kosztuje tyle samo. Wiedza o tym, które elementy generują koszty, pozwala nad nimi zapanować.
Kontenery aplikacji — umiarkowany koszt, ale warto je utrzymać. To właśnie ta część jest naprawdę potrzebna. Można ją też dobrze zmniejszyć, ponieważ preview nie potrzebuje tyle pamięci co produkcja.
Bazy danych — najdroższy element. Dedykowana baza danych dla każdego środowiska preview to największy pojedynczy składnik kosztów i zwykle najmniej potrzebny. Większość review nie wymaga odizolowanej bazy — potrzebuje jakiejś bazy z wiarygodnymi danymi.
Minuty buildów — niewidoczne i narastające. Każdy push do otwartego PR-a uruchamia kolejny build. Branch z czterdziestoma commitami w ciągu dwóch tygodni zbuduje się czterdzieści razy. To realny koszt, który nigdy nie pojawia się jako działający zasób, więc całkowicie umyka pamięciowej kontroli wydatków.
Egress — mały dla pojedynczego preview, duży łącznie. Adresy URL środowisk preview są odkrywane i indeksowane. Crawler pobierający assety z ośmiu środowisk preview wykonuje osiem razy więcej pracy niż w przypadku produkcji, a płacicie za całość.
Cztery sposoby na obniżenie kosztów bez utraty korzyści
Współdziel bazę danych
W przypadku większości zmian środowiska preview mogą współdzielić jedną bazę danych z reprezentatywnymi danymi. Odizolowane bazy warto rezerwować dla PR-ów, które rzeczywiście ich potrzebują — migracji, zmian schematu i operacji destrukcyjnych.
Zasada, która sprawdza się w praktyce: odizolowana baza danych tylko wtedy, gdy PR dotyczy schematu. Cała reszta korzysta ze współdzielonej bazy.
Zmniejsz środowisko preview
Preview obsługujące jednego reviewera nie potrzebuje zasobów produkcji. Połowa pamięci i ułamek CPU są zwykle niezauważalne dla osoby wykonującej review, a jednocześnie znacząco obniżają koszty.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Wygaszaj je
To zmiana o największym wpływie. Środowisko preview nie powinno działać dłużej niż jego pull request.
Automatyczne usuwanie po merge’u lub zamknięciu PR-a to absolutne minimum. Problemem, który zaskakuje zespoły, są porzucone PR-y — branche otwarte przez kogoś, kto został oddelegowany do innych zadań i nigdy ich nie zamknął. Powiązane z nimi środowiska działają przez miesiące.
Warto ustawić maksymalny czas życia: każde środowisko preview starsze niż, na przykład, czternaście dni zostaje usunięte niezależnie od stanu PR-a. Jeśli będzie potrzebne ponownie, wystarczy jedna komenda.
Wyklucz je z wyszukiwarek
Adresy URL środowisk preview są indeksowane. To problem z dwóch powodów — zduplikowana treść konkuruje z witryną produkcyjną, a crawlery generują ruch, za który płacicie, mimo że nikt nie korzysta z tych środowisk.
dockup noindex my-project/my-api --on
W Dockup preview dla PR-ów jest konfigurowane per service i można je jawnie włączać lub wyłączać, zamiast dziedziczyć je z ustawienia globalnego:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
To właśnie z listowania zespoły często rezygnują, a potem tego żałują. Środowiska, których nie potraficie wyświetlić, to środowiska, za które płacicie, nie wiedząc o tym.
Audyt, który warto robić raz w miesiącu
Trzy pytania, pięć minut:
- Ile środowisk preview działa? Porównaj tę liczbę z liczbą faktycznie otwartych PR-ów.
- Jak stare jest najstarsze? Wszystko, co ma więcej niż dwa tygodnie, niemal na pewno jest porzucone.
- Które środowiska mają własną bazę danych? Jeśli zmiana nie dotyczy schematu, własna baza prawdopodobnie nie jest potrzebna.
Większość zespołów znajduje co najmniej jedno środowisko powiązane z PR-em zmergowanym kilka miesięcy temu — nadal działające i nadal generujące koszty.
Jak czerpać korzyści bez niespodzianek
Nie jest to argument przeciwko środowiskom preview. Chodzi o traktowanie ich jak infrastruktury z cyklem życia, a nie jak opcji do odhaczenia.
Zespoły, które dobrze to zorganizowały, robią trzy rzeczy: zmniejszają środowiska preview, wygaszają je i współdzielą wszystko, co można bezpiecznie współdzielić. Dzięki temu cała infrastruktura preview zwykle kosztuje mniej niż pojedynczy service produkcyjny — a przy takim poziomie kosztów korzyści są oczywiste.
Zaskoczenie pojawia się u zespołów, które włączyły tę funkcję raz, poprawnie, a potem nigdy więcej nie zajrzały do listy środowisk.
Najczęściej zadawane pytania
Czy środowiska preview kosztują tyle samo co produkcja? W przeliczeniu na środowisko mogą kosztować tyle samo, jeśli są tworzone identycznie. Po zmniejszeniu zasobów i współdzieleniu bazy danych środowisko preview zwykle kosztuje ułamek tego, co produkcja.
Czy każde środowisko preview powinno mieć własną bazę danych? Tylko wtedy, gdy zmiana dotyczy schematu. Jedna współdzielona baza z przygotowanymi danymi wystarcza do większości review i eliminuje największy składnik kosztów.
Co dzieje się ze środowiskiem preview po zamknięciu PR-a? Powinno zostać automatycznie usunięte. Jeśli tak się nie stanie, będziecie gromadzić środowiska powiązane z PR-ami, o których nikt już nie pamięta.
Czy środowiska preview szkodzą SEO?
Mogą, jeśli zostaną zindeksowane — zduplikowana treść będzie konkurować z produkcyjnymi stronami. Oznacz je jako noindex, co dodatkowo uniemożliwi crawlerom generowanie ruchu, za który płacicie.