Koszty ukryte w złej strategii CI/CD w małej firmie – 3 błędy

Koszty ukryte w złej strategii CI/CD w małej firmie – 3 błędy

CI/CD (Continuous Integration/Continuous Deployment) to standard w nowoczesnym developmentcie. Ale dla małej firmy, gdzie każda minuta i każdy dolar się liczą, źle skonfigurowany pipeline może stać się cichym zabójcą budżetu. W tym artykule pokażę trzy konkretne błędy, które widziałem u klientów – i które kosztowały ich tysiące złotych miesięcznie.

1. Zbyt częste uruchamianie pełnych pipeline’ów

Zaczynajmy od klasyka: pipeline uruchamia się przy każdym commicie – nawet dla drobnych zmian w dokumentacji czy plikach konfiguracyjnych. W teorii to zgodne z ideą CI – „integruj jak najczęściej”. W praktyce, jeśli Twój zespół pushuje 20-30 commitów dziennie, a każdy pipeline trwa 15 minut, to godziny budowania sumują się do… 5-7 godzin dziennie. Przy cenach chmurowych (np. GitHub Actions lub GitLab CI) to prosta droga do przekroczenia limitów i dodatkowych opłat.

Realny przykład: Firma z 5 developerami, która budowała aplikację Node.js + React. Ich pipeline zawierał: lintowanie, testy jednostkowe, testy integracyjne, budowanie obrazów Docker i deploy na staging. Całość trwała 18 minut. Przy 25 commitach dziennie = 450 minut buildów. Miesięcznie: 225 godzin. Koszt na GitHub Actions: przy planie Team ($4/user) darmowe 3000 minut na miesiąc. Po przekroczeniu – $0.008 za minutę. Czyli dodatkowe ~$100/miesiąc za sam build. A to tylko wierzchołek góry lodowej – czas deweloperów też jest kosztem.

Jak to naprawić?

• Użyj triggerów różnicujących: dla gałęzi main pełny pipeline, dla feature tylko testy i lint.
• Wprowadź cachowanie zależności (npm, pip, docker layers). To skraca czas nawet o 70%.
• Zastosuj równoległość – testy jednostkowe i integracyjne mogą biec niezależnie.

2. Brak strategii na artefakty i wersjonowanie

Drugi błąd: każdy build produkuje nowy artefakt (np. obraz Docker), ale nie ma polityki ich przechowywania. Po tygodniu masz 50 nieużywanych obrazów, które zajmują miejsce w rejestrze (np. Docker Hub, AWS ECR, własny Harbor). Koszt przechowywania jest liniowy – na AWS ECR za 100 GB płacisz około $0.10 za GB miesięcznie. Brzmi mało? Jeśli każdy obraz waży 500 MB, a buildów masz 100 miesięcznie, to 50 GB – czyli $5. Niby nic, ale gdy dołożysz koszt skanowania bezpieczeństwa (każdy obraz skanowany osobno) i czas na czyszczenie, robi się z tego kilkadziesiąt dolarów miesięcznie. Do tego dochodzi ryzyko – stare obrazy z lukami mogą być przypadkiem użyte.

Realny przykład: Klient z e-commerce przechowywał obrazy z 6 miesięcy – łącznie 300 GB. Koszt AWS ECR: $0.10/GB/miesiąc za pierwsze 500 GB, ale doliczając transfer (push/pull) i skanowanie (Clair/Snyk), uzbierało się $45/miesiąc. Po wdrożeniu polityki retencji (30 dni dla nightly buildów, 90 dla release) spadło do $8.

Jak to naprawić?

• Zdefiniuj politykę retencji: np. obrazy z gałęzi feature usuń po 7 dniach, z develop po 30, release’y trzymaj dłużej.
• Taguj obrazy semantycznie: v1.2.3, commit-sha, nie latest (bo to zamazuje historię).
• Użyj skryptów lub wbudowanych reguł czyszczenia (np. GitLab Cleanup Policy).

3. Jeden pipeline dla wszystkiego

Małe firmy często mają jedno repozytorium (monorepo) i jeden pipeline, który buduje całość – backend, frontend, skrypty, dokumentację. To wygodne, ale kosztowne. Jeśli zmienisz tylko jeden plik w frontendzie, pipeline i tak uruchomi wszystkie etapy: build frontendu, build backendu, testy backendu, integrację, deploy na staging. To marnowanie czasu i pieniędzy.

Realny przykład: Startup SaaS z monorepo, gdzie pipeline budował całość w 25 minut. Codziennie 10 commitów – 250 minut. 50% z nich dotyczyło tylko frontendu, a backend nie musiał być przebudowywany. Po podziale na dwa osobne pipeline’y (frontend i backend) z odpowiednimi triggerami, średni czas spadł do 10 minut (bo zmiany we frontendzie nie triggerowały backendu). Oszczędność czasu: 125 minut dziennie. Rocznie to ~450 godzin zaoszczędzonego czasu buildów.

Jak to naprawić?

• Użyj paths lub changes w konfiguracji pipeline’u (GitHub Actions: on: push: paths: - 'frontend/**').
• Jeśli to możliwe, wydziel osobne repozytoria dla niezależnych serwisów (mikroserwisy).
• Rozważ narzędzia takie jak Nx lub Turborepo, które inteligentnie określają, co trzeba przebudować.

Podsumowanie

CI/CD to nie tylko automatyzacja – to także zarządzanie kosztami. Zbyt częste buildy, brak polityki retencji i monolityczne pipeline’y to trzy błędy, które widzę najczęściej u małych firm. Każdy z nich generuje ukryte koszty – zarówno bezpośrednie (rachunki za chmurę), jak i pośrednie (czas deweloperów na czekanie).

Dobre praktyki:

• Różnicuj pipeline’y w zależności od gałęzi.
• Cachuj zależności i warstwy Docker.
• Ustaw politykę retencji artefaktów.
• Triggeruj tylko zmienione części.

Jeśli chcesz przejrzeć swoją strategię CI/CD, umów się na konsultację. Często wystarczy kilka drobnych zmian, by zaoszczędzić tysiące rocznie.