CI\/CD \u2013 ci\u0105g\u0142a integracja i ci\u0105g\u0142e dostarczanie \u2013 brzmi jak must-have ka\u017cdej nowoczesnej firmy. I s\u0142usznie, bo automatyzacja build\u00f3w, test\u00f3w i deployment\u00f3w oszcz\u0119dza czas i redukuje b\u0142\u0119dy. Jednak w ma\u0142ych firmach cz\u0119sto implementuje si\u0119 CI\/CD na szybko, bez g\u0142\u0119bszej refleksji. Efekt? Zamiast przyspiesza\u0107, pipeline staje si\u0119 w\u0105skim gard\u0142em, generuje niepotrzebne koszty i frustracj\u0119 zespo\u0142u. W tym artykule poka\u017c\u0119 trzy najcz\u0119stsze b\u0142\u0119dy w strategii CI\/CD, kt\u00f3re widz\u0119 u klient\u00f3w \u2013 i podpowiem, jak je naprawi\u0107.<\/p>\n
Wielu developer\u00f3w w ma\u0142ych firmach narzeka: \u201ePushuj\u0119 kod, a potem czekam 20 minut na zielone \u015bwiat\u0142o\u201d. D\u0142ugi pipeline to wr\u00f3g produktywno\u015bci. Zamiast p\u0142ynnie przechodzi\u0107 do kolejnego zadania, programista przerywa prac\u0119, sprawdza status, poprawia b\u0142\u0119dy i czeka ponownie. Badania pokazuj\u0105, \u017ce przerwanie koncentracji na 10 minut mo\u017ce kosztowa\u0107 nawet 23 minuty na powr\u00f3t do pe\u0142nego skupienia.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Rozwi\u0105zanie:<\/strong> Ka\u017cdy pipeline w popularnych narz\u0119dziach (GitHub Actions, GitLab CI, Jenkins) zaczyna si\u0119 od czystego \u015brodowiska. Je\u015bli nie skonfigurujesz cache\u2019owania zale\u017cno\u015bci (node_modules, vendor, .m2), za ka\u017cdym razem pobierasz je od nowa. Dla projektu z 200+ pakietami npm to 3-5 minut samego czekania na npm install. Pomn\u00f3\u017c przez 20 build\u00f3w dziennie \u2013 godzina stracona ka\u017cdego dnia.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Rozwi\u0105zanie:<\/strong> Typowy scenariusz: pipeline si\u0119 psuje, developer dostaje powiadomienie, ale nie ma czasu od razu zaj\u0105\u0107 si\u0119 b\u0142\u0119dem. Odk\u0142ada na p\u00f3\u017aniej. Tymczasem kolejni developerzy pushuj\u0105 zmiany, kt\u00f3re te\u017c padaj\u0105 na tym samym b\u0142\u0119dzie. Ka\u017cdy traci czas na analiz\u0119, a zesp\u00f3\u0142 dryfuje w chaosie.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Rozwi\u0105zanie:<\/strong> CI\/CD to nie tylko automatyzacja \u2013 to strategia, kt\u00f3ra wp\u0142ywa na tempo rozwoju, morale zespo\u0142u i koszty operacyjne. Zbyt d\u0142ugie pipeline\u2019y, brak cache\u2019owania i ignorowanie nieudanych build\u00f3w to trzy g\u0142\u00f3wne b\u0142\u0119dy, kt\u00f3re widz\u0119 w ma\u0142ych firmach. Poprawa tych obszar\u00f3w nie wymaga du\u017cych nak\u0142ad\u00f3w \u2013 cz\u0119sto wystarczy przemy\u015blana konfiguracja i dobra komunikacja w zespole.<\/p>\n Je\u015bli czujesz, \u017ce Tw\u00f3j pipeline nie dzia\u0142a tak, jak powinien, warto zrobi\u0107 audyt. Cz\u0119sto okazuje si\u0119, \u017ce godzina optymalizacji zwraca si\u0119 dziesi\u0119ciokrotnie w skr\u00f3conym czasie wdro\u017ce\u0144 i mniejszej liczbie b\u0142\u0119d\u00f3w. A w ma\u0142ej firmie ka\u017cda zaoszcz\u0119dzona godzina to wi\u0119cej czasu na rozw\u00f3j produktu.<\/p>\n","protected":false},"excerpt":{"rendered":" Wprowadzenie CI\/CD \u2013 ci\u0105g\u0142a integracja i ci\u0105g\u0142e dostarczanie \u2013 brzmi jak must-have ka\u017cdej nowoczesnej firmy. I s\u0142usznie, bo automatyzacja build\u00f3w, test\u00f3w i deployment\u00f3w oszcz\u0119dza czas i redukuje b\u0142\u0119dy. Jednak w ma\u0142ych firmach cz\u0119sto implementuje si\u0119 CI\/CD na szybko, bez g\u0142\u0119bszej refleksji. Efekt? Zamiast przyspiesza\u0107, pipeline staje si\u0119 w\u0105skim gard\u0142em, generuje niepotrzebne koszty i frustracj\u0119 zespo\u0142u.<\/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":[4,482,120,570],"class_list":["post-2135","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-automatyzacja","tag-bledy-w-devops","tag-ci-cd","tag-mala-firma"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2135","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=2135"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2135\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2135"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2135"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2135"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nKlient (firma SaaS z 6 developerami) mia\u0142 pipeline, kt\u00f3ry uruchamia\u0142 pe\u0142n\u0105 bateri\u0119 test\u00f3w integracyjnych, end-to-end i skan\u00f3w bezpiecze\u0144stwa przy ka\u017cdym pushu. \u015aredni czas wykonania \u2013 35 minut. Deweloperzy wciskali zmiany raz dziennie, aby nie traci\u0107 czasu. Efekt? Rzadkie commity, wi\u0119ksze ryzyko konflikt\u00f3w i op\u00f3\u017anienia w release\u2019ach.<\/p>\n
\nPodziel pipeline na etapy. Szybkie testy jednostkowe i lintery uruchamiaj przy ka\u017cdym pushu (powinny zaj\u0105\u0107 <5 minut). Testy integracyjne i end-to-end \u2013 tylko na g\u0142\u00f3wnym branchu lub przy pull requestach przed mergem. Skanowanie bezpiecze\u0144stwa \u2013 raz na dzie\u0144 lub przy release candidate. Skr\u00f3cenie feedback loop do 2-3 minut natychmiast podnios\u0142o szybko\u015b\u0107 wdro\u017ce\u0144 o 40%.<\/p>\n2. Brak cache\u2019owania zale\u017cno\u015bci \u2013 niepotrzebne pobieranie na nowo<\/h2>\n
\nFirma e-commerce u\u017cywa\u0142a GitHub Actions bez cache. \u015aredni czas instalacji zale\u017cno\u015bci \u2013 4 minuty. Po dodaniu cache (wystarczy doda\u0107 odpowiedni\u0105 akcj\u0119) czas spad\u0142 do 30 sekund. Oszcz\u0119dno\u015b\u0107? Oko\u0142o 10 godzin miesi\u0119cznie na jeden pipeline. Dla trzech pipeline\u2019\u00f3w \u2013 30 godzin, czyli prawie tydzie\u0144 pracy jednego developera.<\/p>\n
\nW ka\u017cdym narz\u0119dziu CI\/CD zaimplementuj cache\u2019owanie. W GitHub Actions u\u017cyj akcji actions\/cache<\/code>. W GitLab CI \u2013 klucz cache<\/code> w konfiguracji. Ustaw odpowiednie klucze (np. hash pliku package-lock.json), aby cache by\u0142 od\u015bwie\u017cany tylko przy zmianach zale\u017cno\u015bci.<\/p>\n3. Brak strategii na nieudane buildu \u2013 ignorowanie b\u0142\u0119d\u00f3w to strata czasu<\/h2>\n
\nW jednej z firm testy jednostkowe zawiera\u0142y flaky test \u2013 test, kt\u00f3ry czasem przechodzi, czasem nie. Nikt nie traktowa\u0142 go powa\u017cnie. Zesp\u00f3\u0142 przyzwyczai\u0142 si\u0119 do klikania \u201eRerun\u201d. W ci\u0105gu miesi\u0105ca flaky test generowa\u0142 15 niepotrzebnych rerun\u00f3w, ka\u017cdy po 10 minut \u2013 2,5 godziny czystej straty. A do tego demoralizacja: \u201ei tak mo\u017ce przej\u015b\u0107 nast\u0119pnym razem\u201d.<\/p>\n
\nUstal polityk\u0119: je\u015bli pipeline jest czerwony (z wyj\u0105tkiem znanych flaky test\u00f3w) \u2013 zesp\u00f3\u0142 zatrzymuje si\u0119 i priorytetowo naprawia. Flaky testy powinny by\u0107 oznaczane i naprawiane w maksymalnie 2 dni. Rozwa\u017c wprowadzenie mechanizmu \u201estop the line\u201d \u2013 je\u015bli build pada, dalsze mergowanie do g\u0142\u00f3wnego brancha jest blokowane do czasu naprawy. To dyscyplinuje zesp\u00f3\u0142 i zapobiega kumulacji d\u0142ugu technicznego.<\/p>\nPodsumowanie<\/h2>\n