{"id":2326,"date":"2026-06-26T15:00:39","date_gmt":"2026-06-26T15:00:39","guid":{"rendered":"https:\/\/news.jurskitech.pl\/blog\/uncategorized\/koszty-ukryte-w-zlej-strategii-ci-cd-w-malej-firmie-3-bledy\/"},"modified":"2026-06-26T15:00:39","modified_gmt":"2026-06-26T15:00:39","slug":"koszty-ukryte-w-zlej-strategii-ci-cd-w-malej-firmie-3-bledy","status":"publish","type":"post","link":"https:\/\/news.jurskitech.pl\/blog\/warto-wiedziec\/koszty-ukryte-w-zlej-strategii-ci-cd-w-malej-firmie-3-bledy\/","title":{"rendered":"Koszty ukryte w z\u0142ej strategii CI\/CD w ma\u0142ej firmie \u2013 3 b\u0142\u0119dy"},"content":{"rendered":"<h2 id=\"kosztyukrytewzejstrategiicicdwmaejfirmie3bdy\">Koszty ukryte w z\u0142ej strategii CI\/CD w ma\u0142ej firmie \u2013 3 b\u0142\u0119dy<\/h2>\n<p>CI\/CD (Continuous Integration\/Continuous Deployment) to standard w nowoczesnym developmentcie. Ale dla ma\u0142ej firmy, gdzie ka\u017cda minuta i ka\u017cdy dolar si\u0119 licz\u0105, \u017ale skonfigurowany pipeline mo\u017ce sta\u0107 si\u0119 cichym zab\u00f3jc\u0105 bud\u017cetu. W tym artykule poka\u017c\u0119 trzy konkretne b\u0142\u0119dy, kt\u00f3re widzia\u0142em u klient\u00f3w \u2013 i kt\u00f3re kosztowa\u0142y ich tysi\u0105ce z\u0142otych miesi\u0119cznie.<\/p>\n<h3 id=\"1zbytczsteuruchamianiepenychpipelinew\">1. Zbyt cz\u0119ste uruchamianie pe\u0142nych pipeline\u2019\u00f3w<\/h3>\n<p>Zaczynajmy od klasyka: pipeline uruchamia si\u0119 przy ka\u017cdym commicie \u2013 nawet dla drobnych zmian w dokumentacji czy plikach konfiguracyjnych. W teorii to zgodne z ide\u0105 CI \u2013 \u201eintegruj jak najcz\u0119\u015bciej\u201d. W praktyce, je\u015bli Tw\u00f3j zesp\u00f3\u0142 pushuje 20-30 commit\u00f3w dziennie, a ka\u017cdy pipeline trwa 15 minut, to godziny budowania sumuj\u0105 si\u0119 do\u2026 5-7 godzin dziennie. Przy cenach chmurowych (np. GitHub Actions lub GitLab CI) to prosta droga do przekroczenia limit\u00f3w i dodatkowych op\u0142at.<\/p>\n<p><strong>Realny przyk\u0142ad:<\/strong> Firma z 5 developerami, kt\u00f3ra budowa\u0142a aplikacj\u0119 Node.js + React. Ich pipeline zawiera\u0142: lintowanie, testy jednostkowe, testy integracyjne, budowanie obraz\u00f3w Docker i deploy na staging. Ca\u0142o\u015b\u0107 trwa\u0142a 18 minut. Przy 25 commitach dziennie = 450 minut build\u00f3w. Miesi\u0119cznie: 225 godzin. Koszt na GitHub Actions: przy planie Team ($4\/user) darmowe 3000 minut na miesi\u0105c. Po przekroczeniu \u2013 $0.008 za minut\u0119. Czyli dodatkowe ~$100\/miesi\u0105c za sam build. A to tylko wierzcho\u0142ek g\u00f3ry lodowej \u2013 czas deweloper\u00f3w te\u017c jest kosztem.<\/p>\n<p><strong>Jak to naprawi\u0107?<\/strong><\/p>\n<ul>\n<li>U\u017cyj trigger\u00f3w r\u00f3\u017cnicuj\u0105cych: dla ga\u0142\u0119zi <code>main<\/code> pe\u0142ny pipeline, dla <code>feature<\/code> tylko testy i lint.<\/li>\n<li>Wprowad\u017a cachowanie zale\u017cno\u015bci (npm, pip, docker layers). To skraca czas nawet o 70%.<\/li>\n<li>Zastosuj r\u00f3wnoleg\u0142o\u015b\u0107 \u2013 testy jednostkowe i integracyjne mog\u0105 biec niezale\u017cnie.<\/li>\n<\/ul>\n<h3 id=\"2brakstrategiinaartefaktyiwersjonowanie\">2. Brak strategii na artefakty i wersjonowanie<\/h3>\n<p>Drugi b\u0142\u0105d: ka\u017cdy build produkuje nowy artefakt (np. obraz Docker), ale nie ma polityki ich przechowywania. Po tygodniu masz 50 nieu\u017cywanych obraz\u00f3w, kt\u00f3re zajmuj\u0105 miejsce w rejestrze (np. Docker Hub, AWS ECR, w\u0142asny Harbor). Koszt przechowywania jest liniowy \u2013 na AWS ECR za 100 GB p\u0142acisz oko\u0142o $0.10 za GB miesi\u0119cznie. Brzmi ma\u0142o? Je\u015bli ka\u017cdy obraz wa\u017cy 500 MB, a build\u00f3w masz 100 miesi\u0119cznie, to 50 GB \u2013 czyli $5. Niby nic, ale gdy do\u0142o\u017cysz koszt skanowania bezpiecze\u0144stwa (ka\u017cdy obraz skanowany osobno) i czas na czyszczenie, robi si\u0119 z tego kilkadziesi\u0105t dolar\u00f3w miesi\u0119cznie. Do tego dochodzi ryzyko \u2013 stare obrazy z lukami mog\u0105 by\u0107 przypadkiem u\u017cyte.<\/p>\n<p><strong>Realny przyk\u0142ad:<\/strong> Klient z e-commerce przechowywa\u0142 obrazy z 6 miesi\u0119cy \u2013 \u0142\u0105cznie 300 GB. Koszt AWS ECR: $0.10\/GB\/miesi\u0105c za pierwsze 500 GB, ale doliczaj\u0105c transfer (push\/pull) i skanowanie (Clair\/Snyk), uzbiera\u0142o si\u0119 $45\/miesi\u0105c. Po wdro\u017ceniu polityki retencji (30 dni dla nightly build\u00f3w, 90 dla release) spad\u0142o do $8.<\/p>\n<p><strong>Jak to naprawi\u0107?<\/strong><\/p>\n<ul>\n<li>Zdefiniuj polityk\u0119 retencji: np. obrazy z ga\u0142\u0119zi <code>feature<\/code> usu\u0144 po 7 dniach, z <code>develop<\/code> po 30, release&#8217;y trzymaj d\u0142u\u017cej.<\/li>\n<li>Taguj obrazy semantycznie: <code>v1.2.3<\/code>, <code>commit-sha<\/code>, nie <code>latest<\/code> (bo to zamazuje histori\u0119).<\/li>\n<li>U\u017cyj skrypt\u00f3w lub wbudowanych regu\u0142 czyszczenia (np. GitLab Cleanup Policy).<\/li>\n<\/ul>\n<h3 id=\"3jedenpipelinedlawszystkiego\">3. Jeden pipeline dla wszystkiego<\/h3>\n<p>Ma\u0142e firmy cz\u0119sto maj\u0105 jedno repozytorium (monorepo) i jeden pipeline, kt\u00f3ry buduje ca\u0142o\u015b\u0107 \u2013 backend, frontend, skrypty, dokumentacj\u0119. To wygodne, ale kosztowne. Je\u015bli zmienisz tylko jeden plik w frontendzie, pipeline i tak uruchomi wszystkie etapy: build frontendu, build backendu, testy backendu, integracj\u0119, deploy na staging. To marnowanie czasu i pieni\u0119dzy.<\/p>\n<p><strong>Realny przyk\u0142ad:<\/strong> Startup SaaS z monorepo, gdzie pipeline budowa\u0142 ca\u0142o\u015b\u0107 w 25 minut. Codziennie 10 commit\u00f3w \u2013 250 minut. 50% z nich dotyczy\u0142o tylko frontendu, a backend nie musia\u0142 by\u0107 przebudowywany. Po podziale na dwa osobne pipeline\u2019y (frontend i backend) z odpowiednimi triggerami, \u015bredni czas spad\u0142 do 10 minut (bo zmiany we frontendzie nie triggerowa\u0142y backendu). Oszcz\u0119dno\u015b\u0107 czasu: 125 minut dziennie. Rocznie to ~450 godzin zaoszcz\u0119dzonego czasu build\u00f3w.<\/p>\n<p><strong>Jak to naprawi\u0107?<\/strong><\/p>\n<ul>\n<li>U\u017cyj <code>paths<\/code> lub <code>changes<\/code> w konfiguracji pipeline\u2019u (GitHub Actions: <code>on: push: paths: - 'frontend\/**'<\/code>).<\/li>\n<li>Je\u015bli to mo\u017cliwe, wydziel osobne repozytoria dla niezale\u017cnych serwis\u00f3w (mikroserwisy).<\/li>\n<li>Rozwa\u017c narz\u0119dzia takie jak Nx lub Turborepo, kt\u00f3re inteligentnie okre\u015blaj\u0105, co trzeba przebudowa\u0107.<\/li>\n<\/ul>\n<h3 id=\"podsumowanie\">Podsumowanie<\/h3>\n<p>CI\/CD to nie tylko automatyzacja \u2013 to tak\u017ce zarz\u0105dzanie kosztami. Zbyt cz\u0119ste buildy, brak polityki retencji i monolityczne pipeline\u2019y to trzy b\u0142\u0119dy, kt\u00f3re widz\u0119 najcz\u0119\u015bciej u ma\u0142ych firm. Ka\u017cdy z nich generuje ukryte koszty \u2013 zar\u00f3wno bezpo\u015brednie (rachunki za chmur\u0119), jak i po\u015brednie (czas deweloper\u00f3w na czekanie).<\/p>\n<p>Dobre praktyki:<\/p>\n<ul>\n<li>R\u00f3\u017cnicuj pipeline\u2019y w zale\u017cno\u015bci od ga\u0142\u0119zi.<\/li>\n<li>Cachuj zale\u017cno\u015bci i warstwy Docker.<\/li>\n<li>Ustaw polityk\u0119 retencji artefakt\u00f3w.<\/li>\n<li>Triggeruj tylko zmienione cz\u0119\u015bci.<\/li>\n<\/ul>\n<p>Je\u015bli chcesz przejrze\u0107 swoj\u0105 strategi\u0119 CI\/CD, um\u00f3w si\u0119 na konsultacj\u0119. Cz\u0119sto wystarczy kilka drobnych zmian, by zaoszcz\u0119dzi\u0107 tysi\u0105ce rocznie.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Koszty ukryte w z\u0142ej strategii CI\/CD w ma\u0142ej firmie \u2013 3 b\u0142\u0119dy CI\/CD (Continuous Integration\/Continuous Deployment) to standard w nowoczesnym developmentcie. Ale dla ma\u0142ej firmy, gdzie ka\u017cda minuta i ka\u017cdy dolar si\u0119 licz\u0105, \u017ale skonfigurowany pipeline mo\u017ce sta\u0107 si\u0119 cichym zab\u00f3jc\u0105 bud\u017cetu. W tym artykule poka\u017c\u0119 trzy konkretne b\u0142\u0119dy, kt\u00f3re widzia\u0142em u klient\u00f3w \u2013 i<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[482,120,570,92],"class_list":["post-2326","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-bledy-w-devops","tag-ci-cd","tag-mala-firma","tag-optymalizacja-kosztow"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2326","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2326"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2326\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2326"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2326"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2326"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}