CI\/CD to dla wielu ma\u0142ych firm \u015bwi\u0119ty graal \u2013 obietnica szybszych wdro\u017ce\u0144, mniejszej liczby b\u0142\u0119d\u00f3w i w pe\u0142ni zautomatyzowanego procesu. W praktyce jednak cz\u0119sto ko\u0144czy si\u0119 to frustracj\u0105 i rachunkami, kt\u00f3re rosn\u0105 szybciej ni\u017c aplikacja. Spotka\u0142em si\u0119 z przypadkami, gdzie firma zatrudniaj\u0105ca 5 developer\u00f3w p\u0142aci\u0142a za pipeline\u2019y wi\u0119cej ni\u017c za serwery produkcyjne. Dlaczego? Bo CI\/CD, \u017ale skonfigurowane, zaczyna dzia\u0142a\u0107 przeciwko Tobie.<\/p>\n
W tym artykule poka\u017c\u0119 trzy najcz\u0119stsze b\u0142\u0119dy w strategii CI\/CD, kt\u00f3re \u2013 zamiast oszcz\u0119dza\u0107 czas i pieni\u0105dze \u2013 winduj\u0105 koszty operacyjne. Opowiem o realnych sytuacjach z rynku i podpowiem, jak ich unikn\u0105\u0107.<\/p>\n
Zaczniemy od podstaw: CI\/CD ma reagowa\u0107 na zmiany w kodzie. Ale czy naprawd\u0119 ka\u017cdy commit musi wywo\u0142ywa\u0107 pe\u0142ny pipeline? W jednej z firm, z kt\u00f3rymi wsp\u00f3\u0142pracowa\u0142em, zesp\u00f3\u0142 skonfigurowa\u0142 GitHub Actions tak, \u017ce ka\u017cdy push do dowolnego brancha uruchamia\u0142 pe\u0142n\u0105 kompilacj\u0119, testy, analiz\u0119 statyczn\u0105, budowanie obraz\u00f3w Docker i deploy na \u015brodowisko stagingowe. Efekt? \u015arednio 45 minut czekania na wynik dla ka\u017cdej zmiany, a przy 30 commitach dziennie \u2013 ponad 22 godziny pracy pipeline\u2019u dziennie. Rachunek za minuty obliczeniowe w chmurze poszybowa\u0142 w g\u00f3r\u0119, a developerzy stracili produktywno\u015b\u0107, czekaj\u0105c na zielone \u015bwiat\u0142o.<\/p>\n
Rozwi\u0105zanie:<\/strong> Wdr\u00f3\u017c strategi\u0119 selektywnego uruchamiania. Dla prostych zmian (np. dokumentacja, zmiana README) pomi\u0144 kosztowne etapy. U\u017cyj filtr\u00f3w \u015bcie\u017cek (path filters) \u2013 w GitLab czy GitHub mo\u017cesz zdefiniowa\u0107, kt\u00f3re pliki triggeruj\u0105 pipeline. Dla ga\u0142\u0119zi developerskich wystarczy uruchomi\u0107 tylko testy jednostkowe, a pe\u0142ny build z deployem zarezerwuj dla main\/master. Dzi\u0119ki temu zaoszcz\u0119dzisz nawet 70% czasu wykonywania pipeline\u2019u i obni\u017cysz koszty chmury o po\u0142ow\u0119.<\/p>\n Ka\u017cde uruchomienie pipeline\u2019u generuje artefakty \u2013 skompilowane pliki, obrazy Docker, raporty z test\u00f3w, logi. Wiele firm przechowuje je bez ogranicze\u0144, bo \u201ekiedy\u015b mog\u0105 si\u0119 przyda\u0107\u201d. Problem w tym, \u017ce magazynowanie w chmurze kosztuje \u2013 nie tylko samo sk\u0142adowanie, ale te\u017c transfer danych przy pobieraniu. W jednym z projekt\u00f3w zauwa\u017cy\u0142em, \u017ce zesp\u00f3\u0142 przechowuje artefakty z ka\u017cdego builda od pocz\u0105tku istnienia repozytorium \u2013 przez 2 lata naros\u0142o 500 GB danych. Miesi\u0119czny koszt samego przechowywania wynosi\u0142 oko\u0142o 50 USD, ale do tego dochodzi\u0142y koszty transferu przy ka\u017cdym pobraniu (np. przez developer\u00f3w). \u0141\u0105cznie dawa\u0142o to 200-300 USD miesi\u0119cznie za co\u015b, czego nikt nie u\u017cywa\u0142.<\/p>\n Rozwi\u0105zanie:<\/strong> Ustaw automatyczne czyszczenie starszych artefakt\u00f3w po 30-90 dniach. Wi\u0119kszo\u015b\u0107 narz\u0119dzi CI\/CD (Jenkins, GitLab, GitHub) pozwala na zdefiniowanie polityki przechowywania. Mo\u017cesz te\u017c zostawi\u0107 tylko artefakty z ostatniego udanego builda na branchu g\u0142\u00f3wnym. Logi przydaj\u0105 si\u0119 g\u0142\u00f3wnie przez kilka dni po deployu \u2013 po tym czasie archiwizuj je do ta\u0144szego storage\u2019u (np. AWS Glacier) lub kasuj. W praktyce redukuje to koszty storage\u2019u o 80-90%.<\/p>\n W jednej z ma\u0142ych firm e-commerce pipeline sk\u0142ada\u0142 si\u0119 z 30-minutowych test\u00f3w end-to-end, kt\u00f3re by\u0142y uruchamiane sekwencyjnie na jednym workerze. Co wi\u0119cej, testy te nie by\u0142y podzielone na niezale\u017cne grupy \u2013 ka\u017cdy test czeka\u0142 na poprzedni. Deploy na produkcj\u0119 blokowa\u0142 si\u0119 na 40 minut, a przy cz\u0119stych poprawkach \u2013 developerzy tracili godziny dziennie. Firma p\u0142aci\u0142a za 2 workery Jenkinsa, ale wykorzystywa\u0142a je w 20%.<\/p>\n Rozwi\u0105zanie:<\/strong> Podziel testy na kategorie (jednostkowe, integracyjne, end-to-end) i uruchamiaj je r\u00f3wnolegle na wielu workerach. U\u017cyj narz\u0119dzi takich jak jest –shard (dla Node.js) czy pytest-xdist (dla Pythona). Okre\u015bl timeout dla test\u00f3w \u2013 je\u015bli test nie sko\u0144czy si\u0119 w 5 minut, niech pipeline go przerwie. Dzi\u0119ki temu czas ca\u0142ego pipeline\u2019u skr\u00f3ci si\u0119 nawet 3-4 krotnie, a Ty zap\u0142acisz tylko za rzeczywi\u015bcie wykorzystane minuty obliczeniowe. Dodatkowo warto u\u017cy\u0107 cache\u2019owania zale\u017cno\u015bci (npm, pip, gradle) \u2013 to te\u017c potrafi skr\u00f3ci\u0107 czas o 50%.<\/p>\n CI\/CD to pot\u0119\u017cne narz\u0119dzie, ale tylko wtedy, gdy jest \u015bwiadomie zarz\u0105dzane. W ma\u0142ej firmie ka\u017cda z\u0142ot\u00f3wka si\u0119 liczy, dlatego nie warto p\u0142aci\u0107 za niepotrzebne uruchomienia, wieczne przechowywanie artefakt\u00f3w i \u017ale zoptymalizowane testy. Wdro\u017cenie powy\u017cszych poprawek zajmuje zwykle kilka godzin, a oszcz\u0119dno\u015bci mog\u0105 si\u0119gn\u0105\u0107 tysi\u0119cy z\u0142otych miesi\u0119cznie. Co wi\u0119cej, zyskujecie czas \u2013 zar\u00f3wno dla pipeline\u2019u, jak i dla zespo\u0142u.<\/p>\n Pami\u0119taj: CI\/CD ma Ci pomaga\u0107, a nie dok\u0142ada\u0107 roboty i koszt\u00f3w. Je\u015bli Tw\u00f3j pipeline przypomina maszyn\u0119, kt\u00f3ra je pieni\u0105dze zamiast przyspiesza\u0107 development \u2013 czas na przegl\u0105d. A je\u015bli potrzebujesz wsparcia w optymalizacji, zawsze mo\u017cesz skontaktowa\u0107 si\u0119 z nami \u2013 pomo\u017cemy Ci wycisn\u0105\u0107 z CI\/CD maksimum warto\u015bci przy minimalnych kosztach.<\/p>\n","protected":false},"excerpt":{"rendered":" Wprowadzenie CI\/CD to dla wielu ma\u0142ych firm \u015bwi\u0119ty graal \u2013 obietnica szybszych wdro\u017ce\u0144, mniejszej liczby b\u0142\u0119d\u00f3w i w pe\u0142ni zautomatyzowanego procesu. W praktyce jednak cz\u0119sto ko\u0144czy si\u0119 to frustracj\u0105 i rachunkami, kt\u00f3re rosn\u0105 szybciej ni\u017c aplikacja. Spotka\u0142em si\u0119 z przypadkami, gdzie firma zatrudniaj\u0105ca 5 developer\u00f3w p\u0142aci\u0142a za pipeline\u2019y wi\u0119cej ni\u017c za serwery produkcyjne. Dlaczego? Bo<\/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,58,464],"class_list":["post-2323","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-automatyzacja","tag-bledy-w-devops","tag-ci-cd","tag-koszty-it","tag-small-business"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2323","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=2323"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2323\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}B\u0142\u0105d 2: Przetrzymywanie niepotrzebnych artefakt\u00f3w i log\u00f3w<\/h2>\n
B\u0142\u0105d 3: Zbyt d\u0142ugie testy i brak optymalizacji r\u00f3wnoleg\u0142o\u015bci<\/h2>\n
Podsumowanie<\/h2>\n