Jaki powinien wyglądać projekt by do repo nie trafiały złe kody?

0

63 mikroserwisy, kilkadziesiąt osób w projekcie.
Aby przetestować swoje zmiany, które chcę wrzucić, muszę postawić całą aplikację lokalnie. Odpala 30 min.

Pobieram kody i wszystko rozjebane.
Naprawiam: a to ktoś mapera zgubił, a to ktoś wersji nie podbił, certyfikatu nie dodał, a to corsa dołożył, a to zmiana w jednym mikroserwisie kłóci się ze zmianą w drugim. Po 4 godzinach wreszcie działa.
Kolejnego dnia pobieram świeże kody i wszystko rozjebane rozwalone/popsute/bałagan/syf.

  1. Czy nie powinno być jakiś testów integracycjnych dla deweloperów tak bym nie musiał stawiać całej apki za każdym razem?
  2. Czy nie powinno być jakiegoś środowiska do robienia burdelu, najlepiej dla każdego programisty osobno albo chociaż na 3-4?
  3. Aplikacja postawiona lokalnie i tak sięga do chmur, czy tak powinno być czy moze dane powinny być zamockowane dla profilu lokalnego?

Nie pracowałem nigdy w dużym projekcie, może to tak wszędzie zazwyczaj wygląda?

3

ad 1) powinno byś takie środowisko - stawiane w ramach CI
ad 2) powinno być łatwo postawić kolejne środowisko pracy
ad 3) oczywiście powinna być możliwość pracy całkowicie lokalnie - bez sieci i wszystkich pierdół

Ale czy w dużym projekcie zawsze to tak wygląda?
Różnie.
Zależy od zespołu - im więcej masz architektów spod ciemnej gwiazdy tym mniejsze szanse, że dało się będzie wygodnie pracować. Wydajna środowisko pracy to nie jest ich cel. Ważniejsze jest żeby dojebać gdzies tak kafke, oracle golden gate czy co tam akurat chcą mieć w CV.

Na rozmowach w sprawie pracy pytam o takie rzeczy i sprawdzam jak to działa u programistów. Jeśli goście nie widzą problemu w tym, że mają jednego oracle wspólnego dla 10 programistów i testerów ... to jak to mówią: wstaję i wychodzę. Ale i tak się czasem wrypię w takie coś - czasem u klienta jeden projekt jest super a kilka innych to bagno.

7

NIE PRZETESTOWANE KODY NIE POWINNY BYĆ MERDZOWANE DO MASTERA // przepraszam za krzyk.

Czyli zakładamy że mamy i testy i środowisko wykonujące te testy. Bez tego robi się bagno i syf.

Aby przetestować swoje zmiany, które chcę wrzucić, muszę postawić całą aplikację lokalnie.

Zgaduję że takiego środowiska nie ma bo jakby było wystarczyło by zrobić brancha w gicie lub Pull Requesta

0

@KamilAdam:

KamilAdam napisał(a):

NIE PRZETESTOWANE KODY NIE POWINNY BYĆ MERDZOWANE DO MASTERA // przepraszam za krzyk.

no i testować każdy ma lokalnie, ale takie testowanie trwa 4 godz. a i tak nie wyklikasz wszystkiego. Testy automatyczne załączają się dopiero po wrzuceniu kodu po kilku godzinach i lecą wtedy zgłoszenia, których i tak nikt nie podejmuje od razu.

1

Testy mogą być robione na branchach - również na CI.
I merge do mastera dopiero jak wszystko przejdzie. To jest nawet typowa konfiguracja.

4 godziny to ręczne klikanie czy testy automatyczne?

Testy automatyczne załączają się dopiero po wrzuceniu kodu po kilku godzinach i lecą wtedy zgłoszenia, których i tak nikt nie podejmuje od razu.

No to jakby wiadomo co jest najgorszym punktem.
Pocieszenie jest takie - że da się to zwykle naprawić, ale niezbędne są trzy warunki:
a) ktoś musi umnieć,
b) musi być na to budżet
c) nie można mieć architektów

0
jarekr000000 napisał(a):

Testy mogą być robione na branchach - również na CI.

4 godziny to ręczne klikanie czy testy automatyczne?

4 godziny postawienie srodowiska trwa, bo błędy, problemy i każde odpalenie to 30 min.

7

smuteczek

5
NamingException napisał(a):

63 mikroserwisy, kilkadziesiąt osób w projekcie.

Aby przetestować swoje zmiany, które chcę wrzucić, muszę postawić całą aplikację lokalnie. Odpala 30 min.

Pytanie: na środowiskach (szczególnie produkcyjnych) też wszystkie są stawiane na raz, w jednej wielkiej deploymentowej choreografii? ;)

Pobieram kody i wszystko rozjebane.
Naprawiam: a to ktoś mapera zgubił, a to ktoś wersji nie podbił, certyfikatu nie dodał, a to corsa dołożył, a to zmiana w jednym mikroserwisie kłóci się ze zmianą w drugim. Po 4 godzinach wreszcie działa.
Kolejnego dnia pobieram świeże kody i wszystko rozjebane.

Brzmi jak "robimy mikroserwisy ale nie mamy CI". Widziałem już mikroserwisy z manualnym CD (mój ulubiony antywzorzec Red Flag Law, nie trzeba nawet tych 60+ mikroserwisów żeby zapewnić dzień zabaw i przygód dla wszystkich) ale bez CI z prawdziwego zdarzenia to już grubo.

Pierwsze co bym zrobił:

  • zrobiłbym CI (żeby coś się budowało jak są zmiany na głównym branchu, developie, czy co tam macie) żeby było jakiekolwiek, na Jeninsie, TeamCity, Github Actions, tym Gitlabowym - obojętnie, byle był automat
  • zrobiłbym żeby to CI odpalało się też na PRach i je uwalało
  • zrobiłbym żeby odpalało jakieś testy (jakiekolwiek, jeśli prawie nie ma) i nie dawał wyłączyć. A jak jest źle z testami, to żeby jeszcze krzyczało i waliło po oczach, jak coverage spadnie - nie po to, żeby był jakiś super coverage pod politykę firmy/architekta, tylko żeby niepisanie testów było bardziej upierdliwe niż pisanie
  • zrobiłbym w ustawieniach repozytoriów, żeby nie dało się commitować na masterze i koniec
  • próbowałbym przepchnąć obowiązkowe CR, choć mogłoby się skończyć "przyklepywaniem" PRów na ślepo
  • najlepiej zrobiłbym jeszcze fast-forward-only, żeby nie było że ktoś naplecie precla i popsuje bo nie zrobił rebase i bawił się nieaktualnym KasztanDTO :)
  • jak już robicie te majkroserwisy w jakiejś chmurze, więc zacząłbym rzeźbić jakikolwiek CD i zarządzanie infrastrukturą jak kodem tj. upakować co potrzebne dla danego serwisu w Kubernetesy, Terraformy, Dockery itp. itd. i zakończyć ten smutny odręczny ulepek
  1. Czy nie powinno być jakiś testów integracycjnych dla deweloperów tak bym nie musiał stawiać całej apki za każdym razem?

Można, jak najbardziej, jeszcze jak - np. przez wycięcie zależności danego serwisu z WireMock

  1. Czy nie powinno być jakiegoś środowiska do robienia burdelu, najlepiej dla każdego programisty osobno albo chociaż na 3-4?

Tak, od tego to powinny być środowiska developerskie, najlepiej takie że zrobisz klik-klik i masz, potem klik-klik i zaorasz.

  1. Aplikacja postawiona lokalnie i tak sięga do chmur, czy tak powinno być czy moze dane powinny być zamockowane dla profilu lokalnego?

Idealnie nie jest, ale jeśli nie chcesz odpalać lokalnie na atrapach (in-memory, Localstacku itp - tak potrzebujesz prawdziwego środowiska bo wszystkiego tak nie sprawdzisz) to może nie być wyjścia. Gorzej, że wpinając się lokalnie wpinasz się.. do czego? Zapewne do zasobów używanych już przez jakieś środowisko, albo majstrujesz w nich ręcznie (żeby je sobie stworzyć). W najlepszym razie wpinasz się do deva... tylko skoro dopominasz się o deva, to do czego tak naprawdę się wpinasz?

Nie pracowałem nigdy w dużym projekcie, może to tak wszędzie zazwyczaj wygląda?

Nie wiem jak jest wszędzie, choć obstawiam, że każdy ma swoje grzeszki i swoje błędy ;)

11

Jak znam życie to pewnie większość z tych kilkudziesieciu programistów traci po ileś godzin dziennie na walkę z projektem. Ale jak ktoś poprosi o 2-3 tygodnie na naprawienie (postawienie) CI to się okaże, że nie ma na to czasu.

6

@NamingException uciekaj stamtąd, albo przegadajcie to w zespole że trzeba ten burdel ogarnąć. W normalnym życiu wygląda to tak:

  1. Są testy jednstkowe/integracyjne które możesz w kilka sekund odpalić lokalnie. Nie trzeba NIGDY odpalać aplikacji i czegoś klikać.
  2. Te testy jeśli failują to psują build i blokują merge do mastera. Czyli jak ktoś "zapomniał mapera" to nie zmerguje tego gówna tylko musi najpierw naprawić i ty nigdy tego nie zobaczysz. Jednocześnie każdy merge do mastera powinien wymagać approve po code review.
  3. Oprócz tego masz środowiska testowe/dev na których możesz odpalić konkretny zbudowany branch (zbudowany -> przechodzący testy!) jakimś jednym klikiem z CI. Więc znów nie musisz nic odpalać lokalnie. Powinno się też dać odpalić e2e na tym środowisku.
  4. Oprócz tego jest środowisko testowe/integracyjne na którym lata aktualny master i stukają po nim automatyczne testy e2e i wysyłają notyfikacje jeśli po czyimś merge e2e zaczęły się sypać.
0

No dobrze, Panie Seniorki i Panowie Seniorzy (tak z 10+)

Co byście robili, konkretnie, żeby powiedzmy do lipca, sierpnia poprawić sytuację?

@NamingException zbiera to, w poniedziałek na standupie przekazuje propozycje i nakreśla plan, co czelendżujemy do końca lata.

Zaczynamy w marcu od i mamy do kwietnia to. Bez tego nie ruszymy.
Dalej robimy tamto.

1

@NamingException: problemem nie jest sama aplikacja, ale wkładka mięsna dookoła.
Pytania:

  1. Czy zewnętrzne zasoby (chmury) są konfigurowalne czy zaszyte?
  2. Czy istnieje CI?
  3. Czy usługi są w jakiś sposób izolowane np. w kontenerach?

ps. uciekaj.

2

@BraVolt

  1. Wrzucamy buildy do CI
  2. Blokujemy mergowanie jeśli build failuje
  3. Dodajemy sanity-check test w kodzie, który sprawdza przynajmniej czy aplikacja w ogóle wstaje

To można zrobić w 1 osobo-dzień, nie trzeba całego zespołu blokować na wakacje, a już te 3 punkty załatwią 90% problemów.

Pisanie testów, jeśli ich nie ma, to juz niestety żmudna praca i tego się nie uniknie.

0

Nie wiem czemu wszyscy założyli, że CI u nich w firmie jest i ma resourcy aby apke z 63 budować za kazdym PR :p

2
Schadoow napisał(a):

Nie wiem czemu wszyscy założyli, że CI u nich w firmie jest i ma resourcy aby apke z 63 budować za kazdym PR :p

Jeśli przy mikroserwisach liczonych w dziesiątkach nie mają żadnego CI - a brzmi, jakby nie mieli, więc nie wiem skąd założenie, że zakładamy, że mają - to nawet sobie nie wyobrażam ile czasu muszą tracić na kulanie tego i ręczne zarządzanie, rozwiązywanie problemów itd. I ogólnie brzmi to, jakby zespół dzielił się na tych, którzy już się uzależnili od Stoperanu i na tych, którzy mają to wszystko głęboko w d....

Nie zdziwię się nawet, gdyby próba wprowadzenia CI, testów, CR, zablokowania mastera itd. skończyła się niesamowitym oporem ze strony tych drugich, bo

  • a po co
  • a na co
  • przecież działa, tylko nie umiesz z tym pracować
  • ile z tym roboty będzie? komu to potrzebne?
  • kto będzie pisał te testy? ja nie jestem testerem!
  • no co że się wywala, musi się wywalać, tak to już jest i wtedy robisz fixa i klepiesz dalej, taka kolej rzeczy, naucz się młody

:]

0

@superdurszlak:
Nie chodzi mi czy maja skonfigurowane samo CI. Tylko fizycznie czy mają postawionego(albo wykupiona usługę) jakiegoś gitlaba, jenkinsa itd który to udźwignie.
@Shalom napisał porady zaczynając od "Wrzucamy buildy do CI". I do tego sie odniosłem ;p.

2

Tak jak zostało powiedziane - CI. Rozwiąże to 90% twoich problemów. Ja trafiłem do projektu z mikroserwisami, mamy CI od początku i szczerze mówiąc do dzisiaj nie wiedziałem, że istnieją firmy które pracują w mikroserwisach, pushując na mastera jak im się podoba bez jakiegokolwiek CI.

0

Nie no, Continnouse Integration chyba jest, konfiguracje rozbudowane, Kubernetesy i lasery tylko jak rozumiem brakuje 2 rzeczy: testów automatycznych na wszystkich branczach po wychnieciu kodu (są tylko jednostkowe a automatyczne działają na głównym z opóźnieniem) oraz środowiska na którym można odpalić wybrany brancz.

0

A to te wszystkie mikroserwajsy są tak ze sobą zżyte, że testy automatyczne muszą się odpalać dla nich wszystkich? Nie lepiej podzielić je wg. jakiejś domeny? Zdefiniujcie po prostu w jakimś planie bamboo czy co tam macie żeby odpalało taska mavenowego/gradlowego z testami integracyjnymi/unitami. Poproście o jakieś środowisko devove, na które można tylko snapshoty wgrać (np. z brancza) a na prodzie ustawcie żeby mógł leciec deploy tylko pełnoprawnego release

1 użytkowników online, w tym zalogowanych: 0, gości: 1