Wpis użytkownika WojciechKawulski w Testowanie oprogramowania

@WojciechKawulski 1 dev i 2 QA? Na bogato
u mnie 20 dev i 2 QA xD

@Kazix owszem, od tego jest bugtracker.

@WojciechKawulski U mnie wygląda to tak. Mamy jedną dużą aplikację o architekturze monolitu plus kilkanaście mniejszych wydzielonych zniego z własnym frontem i mikroserwisami. Pracujemy w kilkunastu zespołach różnej wielkości kilku deweloperów plus 1-4 testerów manualnych plus jeden dedykowany automatyk. Aplikacja deployowana jest na 4 środowiskach z różną wersją (jedno dedykowane na nocne automaty z mechanizmem odtwarzania bazy danych). Wszystkie zadania po oddaniu przez deweloperów tesotwane są przed mergem na osobnym feature branchu zbudowanym z tylko zmianami z danego zadania. Jeśli wszystko jest ok zadanie jest mergowane do mastera. Ja jako automatyk pokrywam funkcjonalości równolegle (albo walczę z długiem, w zależności od zespołu) czy to testami UI czy API w zależności co jest potrzebne. Raz na tydzień wydawana jest mniejsza wersja monolitu do klienta (sewisy wydawane są on demand), poprzedzona 1-2 dniowym freezem kodu, stabilizacja i regresją.

Po kiego?

@wojtek-x no chyba dobrze jest dać znać, że bug jest, jakiś ticket czy coś xd

@WojciechKawulski
RM - resource manager,
taki informatyk wyspecjalizowany w wirtualkach, dockerach, serwerach, utrzymaniu, środowiskach, etc
nie klepie zwyczajnego "kodu"

@WojciechKawulski nie potrzebujesz dostępu do kodu. Wystarczy dostęp do SSH serwera na którym stoi repo

@wojtek-x W sumie to nie wiem czemu tak xD Może żebyśmy za dużo nie grzebali w kodzie w takim sensie, że cofniemy coś złego itd.

O serdecznie dziękuję temat dla mnie więc odpowiem :smiley:

u nas w firmie ja tworzyłem środowiska testowe; mamy ich 20 (tworzone z templatek), żadne nie mają dościa z "zewnątrz", ale wszystkie mog wyjść "na zewnątrz". Każde jest podpięte pod inne stanowisko dev. Często jedno środowisko jest współdzielone przez kilku devów (UX/UI/logika/itp),
Devovie mają kodzić, nic poza tym.

uderzami do deva, który te feralną poprawkę wprowadził

Po kiego? Nie prościej jest po prostu dać git revert <commitHash>, ewentualnie (jeśli git status nic podejrzanego nie wywali) git reset --hard <commitHash>?

@WojciechKawulski tak na prawdę w każdej firmie jest inaczej. 😉

@WojciechKawulski raczej nie odpowiem Ci na to pytanie, bo się nie da. Mamy chyba 11 feature teamów, każdy pracuje nad czymś oddzielnym, kwestia jak duży jest feature i w ilu sprintach idzie się zmieścić. Od roku poza tym sprawa wygląda trochę inaczej, bo zmieniamy architekturę na mikroserwisy i niektóre teamy przestały robić ficzerki do platformy, bo pracują nad mikrosami.

@Zielczan Tak z ciekawości, ile tak mniej wiecej nowych featurow dodajecie do aplikacji przy nowym realeasie?

@WojciechKawulski my mamy środowiska - develop do testowania codziennego, release - do testowania w fazie release, 3 dni przed końcem sprintu, testujemy tam jeszcze raz ten sam ficzer, który został już obrobiony na developie. W teorii na Release nie ma już zbyt wielu błędów, bo wszystki zostały wyłapane na developie, w praktyce coś tam się znajduje zawsze.

Jeśli nieprawidłowa praca buildu jest wynikiem jakiejś PRki to naprawia to dev/team odpowiedzialny za obszar, w któyrm jest ta PRka. Jeśli błędy są czysto techniczne to mamy DevOpsów, którzy ogarniaja srodowisko od tej strony.

@Kazix Rozwiniesz?

Jesteście wy za to odpowiedzialni, czy takie rzeczy leżą po stronie devów.

@WojciechKawulski tzw RMów