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.

6

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ć.

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