CI\/CD w chmurze to standard. GitHub Actions, GitLab CI, CircleCI \u2013 ka\u017cda platforma kusi prostot\u0105 i skalowalno\u015bci\u0105. Dla startupu czy ma\u0142ej firmy decyzja wydaje si\u0119 oczywista: \u201enie budujemy w\u0142asnego Jenkinsa, bierzemy gotowca\u201d. Problem w tym, \u017ce te gotowe rozwi\u0105zania potrafi\u0105 generowa\u0107 koszty, o kt\u00f3rych nikt nie m\u00f3wi. Widzia\u0142em projekty, gdzie miesi\u0119czny rachunek za CI\/CD przekracza\u0142 koszty serwer\u00f3w produkcyjnych. W tym artykule poka\u017c\u0119, na co uwa\u017ca\u0107, \u017ceby nie przep\u0142aca\u0107.<\/p>\n
Wi\u0119kszo\u015b\u0107 chmurowych CI\/CD dzia\u0142a w modelu \u2013 p\u0142acisz za czas wykonania, liczb\u0119 r\u00f3wnoleg\u0142ych job\u00f3w, a niekiedy za przechowywanie artefakt\u00f3w. W teorii \u2013 \u015bwietnie. W praktyce \u2013 \u0142atwo o eksplozj\u0119 koszt\u00f3w.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Klient u\u017cywa\u0142 GitHub Actions dla repozytorium z aplikacj\u0105 Node.js. Ka\u017cdy push do brancha wyzwala\u0142 pe\u0142en pipeline: lint, testy, budow\u0119, deploy. W szczycie \u2013 kilkana\u015bcie commit\u00f3w dziennie, ka\u017cdy na 2-3 branchach. Rachunek? Ponad 2000 minut miesi\u0119cznie w p\u0142atnych runnerach. Po optymalizacji \u2013 zeszli\u015bmy do 300 minut. Klient p\u0142aci\u0142 za niepotrzebne buildy na starych branchach.<\/p>\n Konsekwencje dla biznesu:<\/strong> Koszty rosn\u0105 liniowo z liczb\u0105 commit\u00f3w i branchy, a nie z produktywno\u015bci\u0105 zespo\u0142u. Im wi\u0119cej eksperyment\u00f3w, tym wy\u017cszy rachunek.<\/p>\n Ka\u017cda platforma CI\/CD pozwala na cache’owanie node_modules, vendor, .m2 itp. Ale wi\u0119kszo\u015b\u0107 ma\u0142ych firm tego nie robi. Efekt? Za ka\u017cdym razem pobierane s\u0105 te same pakiety \u2013 to zar\u00f3wno czas, jak i pieni\u0105dze.<\/p>\n Jak to naprawi\u0107:<\/strong> Ustaw cache w GitHub Actions:<\/p>\n To proste, ale widz\u0119 to rzadko w projektach poni\u017cej 3 developer\u00f3w.<\/p>\n Domy\u015blna konfiguracja: Jak to naprawi\u0107:<\/strong><\/p>\n Oszcz\u0119dno\u015b\u0107 rz\u0119du 60-80% koszt\u00f3w.<\/p>\n Wi\u0119kszo\u015b\u0107 plan\u00f3w startowych ma limit r\u00f3wnoleg\u0142ych job\u00f3w. Gdy go przekroczysz \u2013 joby czekaj\u0105 w kolejce. Ale kupowanie wy\u017cszego planu (wi\u0119cej r\u00f3wnoleg\u0142o\u015bci) cz\u0119sto nie jest potrzebne. W ma\u0142ym zespole jeden job na raz wystarczy.<\/p>\n Przyk\u0142ad:<\/strong> Klient mia\u0142 plan Pro w CircleCI za 50 USD\/mc, ale wykorzystywa\u0142 \u015brednio 1,2 joba r\u00f3wnolegle. Po zmianie na plan Basic za 30 USD\/mc \u2013 oszcz\u0119dno\u015b\u0107 40%, a czas oczekiwania wzr\u00f3s\u0142 tylko o 10%.<\/p>\n U\u017cywaj self-hosted runner\u00f3w<\/strong> \u2013 je\u015bli masz serwer (nawet ma\u0142ego VPS), postaw w\u0142asnego runnera. Koszt sta\u0142y, nie zale\u017cny od liczby build\u00f3w. Dla ma\u0142ej firmy op\u0142aca si\u0119 ju\u017c przy 5-10 buildach dziennie.<\/p>\n<\/li>\n Wy\u0142\u0105cz pipeline na push do feature branchy<\/strong> \u2013 uruchamiaj tylko na pull request i merga do maina. To najwi\u0119ksza oszcz\u0119dno\u015b\u0107.<\/p>\n<\/li>\n Optymalizuj czas builda<\/strong> \u2013 dziel go na etapy, u\u017cywaj cache, nie instaluj zb\u0119dnych narz\u0119dzi. Ka\u017cda zaoszcz\u0119dzona minuta to mniej p\u0142atnych minut.<\/p>\n<\/li>\n Monitoruj u\u017cycie<\/strong> \u2013 ka\u017cde narz\u0119dzie ma dashboard. Sprawdzaj, ile minut idzie na testy, ile na budow\u0119. Cz\u0119sto testy jednostkowe s\u0105 wykonywane wielokrotnie \u2013 mo\u017cna je uruchamia\u0107 tylko dla zmienionych plik\u00f3w.<\/p>\n<\/li>\n Negocjuj plany<\/strong> \u2013 je\u015bli jeste\u015b startupem, cz\u0119sto mo\u017cna dosta\u0107 zni\u017cki lub darmowe minuty. Wsp\u00f3\u0142pracuj\u0119 z firm\u0105, kt\u00f3ra dosta\u0142a od CircleCI 10 000 darmowych minut na rok.<\/p>\n<\/li>\n<\/ol>\n Nie. Je\u015bli brakuje Ci czasu na administracj\u0119, bezpiecze\u0144stwo jest krytyczne, a przepustowo\u015b\u0107 ma\u0142a \u2013 chmura jest lepsza. Ale nie daj si\u0119 nabra\u0107, \u017ce \u201echmura zawsze si\u0119 op\u0142aca\u201d. Dla stabilnego projektu z 20+ buildami dziennie, w\u0142asny runner zwraca si\u0119 w 3 miesi\u0105ce.<\/p>\n Przyk\u0142ad:<\/strong> Firma e-commerce z 5 developerami. Postawili\u015bmy runnera na serwerze za 40 USD\/mc (np. Hetzner). Poprzedni rachunek w GitHub Actions: 150 USD\/mc. Oszcz\u0119dno\u015b\u0107 110 USD\/mc. Do tego \u2013 pe\u0142na kontrola nad czasem builda (no queue).<\/p>\n CI\/CD w chmurze to wygoda, ale nie oszcz\u0119dno\u015b\u0107 z automatu. Ma\u0142e firmy cz\u0119sto przep\u0142acaj\u0105 przez brak optymalizacji. Zanim wykupisz drogi plan, zoptymalizuj to, co masz \u2013 cache, wyzwalacze, r\u00f3wnoleg\u0142o\u015b\u0107. Dopiero potem rozwa\u017caj w\u0142asnego runnera.<\/p>\n Pami\u0119taj, \u017ce ka\u017cda zaoszcz\u0119dzona minuta w CI to nie tylko pieni\u0105dze, ale i czas Twoich developer\u00f3w \u2013 czekanie na build to utrata produktywno\u015bci. A to ju\u017c koszt, kt\u00f3rego nie wida\u0107 na fakturze.<\/p>\n Je\u015bli potrzebujesz pomocy w audycie koszt\u00f3w chmury lub optymalizacji pipeline’\u00f3w \u2013 JurskiTech ma w tym do\u015bwiadczenie. Pisz \u015bmia\u0142o.<\/p>\n","protected":false},"excerpt":{"rendered":" Wprowadzenie CI\/CD w chmurze to standard. GitHub Actions, GitLab CI, CircleCI \u2013 ka\u017cda platforma kusi prostot\u0105 i skalowalno\u015bci\u0105. Dla startupu czy ma\u0142ej firmy decyzja wydaje si\u0119 oczywista: \u201enie budujemy w\u0142asnego Jenkinsa, bierzemy gotowca\u201d. Problem w tym, \u017ce te gotowe rozwi\u0105zania potrafi\u0105 generowa\u0107 koszty, o kt\u00f3rych nikt nie m\u00f3wi. Widzia\u0142em projekty, gdzie miesi\u0119czny rachunek za CI\/CD<\/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,454,570],"class_list":["post-2343","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-bledy-w-devops","tag-ci-cd","tag-koszty-chmury","tag-mala-firma"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2343","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=2343"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2343\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2343"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2343"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2343"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}3 b\u0142\u0119dy w strategii CI\/CD, kt\u00f3re winduj\u0105 koszty<\/h2>\n
B\u0142\u0105d 1: Brak cache’owania zale\u017cno\u015bci<\/h3>\n
- uses: actions\/cache@v3\n with:\n path: node_modules\n key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}\n<\/code><\/pre>\nB\u0142\u0105d 2: Uruchamianie pipeline’\u00f3w na ka\u017cdym branchu<\/h3>\n
on: [push]<\/code> \u2013 to znaczy, \u017ce ka\u017cdy push wyzwala build. Developer robi 10 commit\u00f3w dziennie na feature branchu \u2013 10 build\u00f3w. A wystarczy uruchamia\u0107 tylko na main<\/code> i na pull requestach.<\/p>\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n<\/code><\/pre>\nB\u0142\u0105d 3: Nieoptymalna konfiguracja r\u00f3wnoleg\u0142o\u015bci<\/h3>\n
Jak realnie obni\u017cy\u0107 koszty CI\/CD w chmurze?<\/h2>\n
\n
Czy self-hosted runner to zawsze opcja?<\/h2>\n
Podsumowanie<\/h2>\n