Wprowadzenie
CI/CD w chmurze to standard. GitHub Actions, GitLab CI, CircleCI – każda platforma kusi prostotą i skalowalnością. Dla startupu czy małej firmy decyzja wydaje się oczywista: „nie budujemy własnego Jenkinsa, bierzemy gotowca”. Problem w tym, że te gotowe rozwiązania potrafią generować koszty, o których nikt nie mówi. Widziałem projekty, gdzie miesięczny rachunek za CI/CD przekraczał koszty serwerów produkcyjnych. W tym artykule pokażę, na co uważać, żeby nie przepłacać.
Dlaczego „pay-as-you-go” w CI/CD nie zawsze działa
Większość chmurowych CI/CD działa w modelu – płacisz za czas wykonania, liczbę równoległych jobów, a niekiedy za przechowywanie artefaktów. W teorii – świetnie. W praktyce – łatwo o eksplozję kosztów.
Przykład z życia: Klient używał GitHub Actions dla repozytorium z aplikacją Node.js. Każdy push do brancha wyzwalał pełen pipeline: lint, testy, budowę, deploy. W szczycie – kilkanaście commitów dziennie, każdy na 2-3 branchach. Rachunek? Ponad 2000 minut miesięcznie w płatnych runnerach. Po optymalizacji – zeszliśmy do 300 minut. Klient płacił za niepotrzebne buildy na starych branchach.
Konsekwencje dla biznesu: Koszty rosną liniowo z liczbą commitów i branchy, a nie z produktywnością zespołu. Im więcej eksperymentów, tym wyższy rachunek.
3 błędy w strategii CI/CD, które windują koszty
Błąd 1: Brak cache’owania zależności
Każda platforma CI/CD pozwala na cache’owanie node_modules, vendor, .m2 itp. Ale większość małych firm tego nie robi. Efekt? Za każdym razem pobierane są te same pakiety – to zarówno czas, jak i pieniądze.
Jak to naprawić: Ustaw cache w GitHub Actions:
- uses: actions/cache@v3
with:
path: node_modules
key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
To proste, ale widzę to rzadko w projektach poniżej 3 developerów.
Błąd 2: Uruchamianie pipeline’ów na każdym branchu
Domyślna konfiguracja: on: [push] – to znaczy, że każdy push wyzwala build. Developer robi 10 commitów dziennie na feature branchu – 10 buildów. A wystarczy uruchamiać tylko na main i na pull requestach.
Jak to naprawić:
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
Oszczędność rzędu 60-80% kosztów.
Błąd 3: Nieoptymalna konfiguracja równoległości
Większość planów startowych ma limit równoległych jobów. Gdy go przekroczysz – joby czekają w kolejce. Ale kupowanie wyższego planu (więcej równoległości) często nie jest potrzebne. W małym zespole jeden job na raz wystarczy.
Przykład: Klient miał plan Pro w CircleCI za 50 USD/mc, ale wykorzystywał średnio 1,2 joba równolegle. Po zmianie na plan Basic za 30 USD/mc – oszczędność 40%, a czas oczekiwania wzrósł tylko o 10%.
Jak realnie obniżyć koszty CI/CD w chmurze?
-
Używaj self-hosted runnerów – jeśli masz serwer (nawet małego VPS), postaw własnego runnera. Koszt stały, nie zależny od liczby buildów. Dla małej firmy opłaca się już przy 5-10 buildach dziennie.
-
Wyłącz pipeline na push do feature branchy – uruchamiaj tylko na pull request i merga do maina. To największa oszczędność.
-
Optymalizuj czas builda – dziel go na etapy, używaj cache, nie instaluj zbędnych narzędzi. Każda zaoszczędzona minuta to mniej płatnych minut.
-
Monitoruj użycie – każde narzędzie ma dashboard. Sprawdzaj, ile minut idzie na testy, ile na budowę. Często testy jednostkowe są wykonywane wielokrotnie – można je uruchamiać tylko dla zmienionych plików.
-
Negocjuj plany – jeśli jesteś startupem, często można dostać zniżki lub darmowe minuty. Współpracuję z firmą, która dostała od CircleCI 10 000 darmowych minut na rok.
Czy self-hosted runner to zawsze opcja?
Nie. Jeśli brakuje Ci czasu na administrację, bezpieczeństwo jest krytyczne, a przepustowość mała – chmura jest lepsza. Ale nie daj się nabrać, że „chmura zawsze się opłaca”. Dla stabilnego projektu z 20+ buildami dziennie, własny runner zwraca się w 3 miesiące.
Przykład: Firma e-commerce z 5 developerami. Postawiliśmy runnera na serwerze za 40 USD/mc (np. Hetzner). Poprzedni rachunek w GitHub Actions: 150 USD/mc. Oszczędność 110 USD/mc. Do tego – pełna kontrola nad czasem builda (no queue).
Podsumowanie
CI/CD w chmurze to wygoda, ale nie oszczędność z automatu. Małe firmy często przepłacają przez brak optymalizacji. Zanim wykupisz drogi plan, zoptymalizuj to, co masz – cache, wyzwalacze, równoległość. Dopiero potem rozważaj własnego runnera.
Pamiętaj, że każda zaoszczędzona minuta w CI to nie tylko pieniądze, ale i czas Twoich developerów – czekanie na build to utrata produktywności. A to już koszt, którego nie widać na fakturze.
Jeśli potrzebujesz pomocy w audycie kosztów chmury lub optymalizacji pipeline’ów – JurskiTech ma w tym doświadczenie. Pisz śmiało.
