Kiedy przyszedłem do projektu, release przez CI/CD trwało 60 min Kiedy odchodziłem trwało to tylko 15 minut Kiedy - Klopsztanga

Kiedy przyszedłem do projektu, release przez CI/CD trwało 60 min
Kiedy odchodziłem trwało to tylko 15 minut
Kiedy powróciłem po roku przerwy - teraz zajmuje 2,5h

Komentarze (22)

cyber_bikerFenomen2 lata temu1

@Klopsztanga trzeba było iść w layer2 a nie jakąś chujnię

Felonious_GruLider2 lata temu1

@Klopsztanga co to jest cicd

PanPaweuDrugiWirtuoz2 lata temu1

@Felonious_Gru w sumie zajebiście wygodne i, o ile działa szybko i stabilnie to programiści bardzo to lubią, bo dostarcza natychmiastowy feedback odnośnie tego, czy się coś spieprzyło. W innym wypadku taki feedback dostarczy Ci klient, a to już takie przyjemne nie jest.

Felonious_GruLider2 lata temu1

@PanPaweuDrugi trochę przerażające, ale sprytne

PanPaweuDrugiWirtuoz2 lata temu1

@Felonious_Gru continuous integration / continuous deployment. W skrócie to automat, który odpala się kiedy programista wrzuca zmiany w kodzie. Ten automat te zmiany testuje, generuje metryki i tworzy paczki gotowe do uruchomienia, często również wdraża zmiany na środowisko testowe / produkcyjne.

rm-rfTytan2 lata temu1

@Klopsztanga zależy co robicie i jak robocie ale jak docker tam leci to możesz sobie layery zrobić mądrze w docker i odpalać build dind, tym sposobem cała warstwa z modules i bin się przeniesie do nowego builda a budujesz tylko zmiany. Co do testów w njs to u nas skończyło się na przepisaniu sorry cypress na swój i wszystko nadal hula w parallel.

AnteczekOsobistość2 lata temu4

@Klopsztanga no i może teraz bilują klienta za 2,5h, a nie 15 minut ( ͡° ͜ʖ ͡°)

wombatDaiquiriGruba ryba2 lata temu0

@Klopsztanga dodajesz ficzer, optymalizujesz jak trzeba. Widocznie nie potrzeba i generujesz problem xD

RagnarokkGURU2 lata temu1

I jest czas na hejto :P

defGruba ryba2 lata temu0

To co tam macie w tym CI/CD? U mnie tylko build dockera -> push do docker huba-> deploy
Reszta rzeczy jak np. testy, analiza statyczna, linty mam ustawione na merge request

globalbusKosmonauta2 lata temu0

@Deykun jak masz głupi filesystem, to pliki się długo kopiują. Copy-on-write przyspiesza wydatnie.

KlopsztangaGruba ryba2 lata temu0

@def aaa :smiley: chyba ze tak :grinning:

defGruba ryba2 lata temu1

@Klopsztanga chodzi mi o to, że używam tego pliku jako klucz cache, wrzucamy go w gita i w CI robimy npm ci

KlopsztangaGruba ryba2 lata temu1

@def package-lock.json nie jest do kontroli cache, tylko do pewnosci ze przetestowane paczki zostana zainstalowane.

Blokuje wersję paczek po prostu :smiley:

defGruba ryba2 lata temu1

@Deykun ja node_modules cache'uje, do kontroli cache'u używam package-lock.json

DeykunLider2 lata temu1

@def
Ja w diffle jak był tylko polski miałem z 10k plików i jak kopiowało każdy osobno to build potrafił trwać pond 40 minut. Jak zacząłem je pakować do .zip i rozpakowywać na miejscu skróciło do minuty. Dzisiaj przy 6 językach to pewnie ten upload by trwał z 5h. dx

Najłatwiej chyba tak nabić jak ktoś nieogranie i zrobi coś podobnego kopiując node_modules, to nawet na tym samym kompie się długo kopiuje plik po pliku. dx

KlopsztangaGruba ryba2 lata temu0

@def a no budowanie dockera + budowanie JS 'a. JS głównie najwolniejszy jest.

DeykunLider2 lata temu21

@Klopsztanga
Trwa tyle, bo jest dopisane tyle testów przed, prawda?
Prawda?

KlopsztangaGruba ryba2 lata temu1

@dahomej każdy to ma w dupie :smiley: Ważne, że ticket odhaczony, nara.

dahomejInspirator2 lata temu0

@Klopsztanga a playwrighta nie da się odpalać równolegle? (czy po prostu tego nie zrobili?)

KlopsztangaGruba ryba2 lata temu0

@Deykun inny przykład: wcześniej paratest , teraz po prostu phpunit :smiley:

KlopsztangaGruba ryba2 lata temu3

@Deykun nie prawda ;( Chodzi o ideę.
Jak wchodziłem, był cypress. No to zoptymalizowałem go by działał horyzontalnie. Podzielony był na workery
Później przepisali to do PlayWright - i działa po kolei.

Wpis użytkownika Klopsztanga w Hydepark

Komentarze (22)