Standardy pracy E2E jako programista

Witam,
od pewnego czasu zastanawiam się nad zmianami w zatrudnieniu chodź zwarzając na obecny #koniec_eldorado jest to raczej plan na przyszły rok.

Mimo wszystko martwię się taką zmianą i to niekoniecznie z powodu różnic technologicznych czy stopniu zaawansowania projektów, a samym podejściem firm w kwestii praktyk end to end.
I już tu wyjaśniam moje obawy. Obecna praca dla korpo mały zespół IT i pracujemy tylko dla siebie ewentualnie integracje z partnerami. Taski otrzymuję z "góry" lub bezpośrednio od użytkowników, sam muszę wykonać analizę ryzyka, możliwość wykonania, wykonanie, testy własne, testy użytkownika na środowisku testowym, zmiany, "testy na produkcji". Pisząc testy na produkcji częściowo mam to na myśli ponieważ nie zawsze jestem w stanie przewidzieć, kto i w jaki sposób wykorzystuje jakąś rozwijaną funkcjonalność przez co nabrałem nawyku parametryzacji każdej pierdoły by móc to jednym parametrem w ustawieniach wyłączyć bez konieczności rollbackowania i większych problemów produkcyjnych.

Chciałbym wiedzieć jak to wygląda z drugiej strony? Mam znajomych programistów w różnych firmach i słyszę różne kwestia od narzekań na długi łańcuch dowodzenia do luźnego podejścia czyt. wykonuje swoją broszkę czyli programuję funkcjonalność według przygotowanego schematu przez konsultanta następnie oddaje do testera który ewentualnie przepchnie to dalej.

Chciałbym być efektywny, a mimo wszystko większość tematu muszę traktować po macoszemu, chodźby testy których nie piszę, a jedynie sprawdzam na faktycznych przypadkach i oddaje użytkownikom do kontroli ze względu na duży zakres biznesowy z którym pracuję.

Nad czym powinienem pracować? Jak faktycznie wygląda w szerszej perspektywie praca w Polsce w warunkach end 2 end?

radek64 napisał(a):

przez co nabrałem nawyku parametryzacji każdej pierdoły by móc to jednym parametrem w ustawieniach wyłączyć bez konieczności rollbackowania i większych problemów produkcyjnych.

Feature flag to częsta praktyka. Alternatywą jest canary deployment i bardzo dobry monitoring, który od razu pokaże, że coś się popsuło.

Tak czy owak to rolą zespołu (jak i twoją) jest proponowanie rozwiązań, które sprawią, że będzie lepiej. Jeśli uważasz, że taki flow jest bardzo ciężki to zaczynasz narzekać, że bez testów development trwa bardzo długo i bardzo łatwo coś zepsuć. Jeśli narzekanie i rozwiązanie zostanie zaakceptowane to fajnie. Jak nie to musisz się zastanowić czy chcesz pracować w takiej firmie

Mam znajomych programistów w różnych firmach i słyszę różne kwestia od narzekań na długi łańcuch dowodzenia do luźnego podejścia czyt. wykonuje swoją broszkę czyli programuję funkcjonalność według przygotowanego schematu przez konsultanta następnie oddaje do testera który ewentualnie przepchnie to dale

Różne firmy próbują rozwiązać ten sam problem tj. jak wypuszczać releasy, które nie psują produkcji różnymi metodami. Jak masz firmę, która robi release co miesiąc/kwartał z różnych powodów np. politycznych (ktoś uznał, że tak ma być i tyle) albo praktycznych (testy trwają bardzo długo i kod musi swoje odsiedzieć)

Z drugiej strony, jeśli releasy powinny być częste (bo biznes tego wymaga) to trzeba się zastanowić jak usprawnić cały ten proces

a jedynie sprawdzam na faktycznych przypadkach

To masz testy tylko manualne. Warto pomyśleć dlaczego w takich przypadkach nie możesz tego zautomatyzować. Najczęściej jest to po prostu brak zestawionego środowiska testowego/lokalnego, bo np. nie potraficie dobrze zreprodukować bazy i API, które są potrzebne do testów w izolacji

Teraz już raczej standardem jest wiele releasów na produkcję codziennie. Są pipeliny z testami (unitami, integracyjnymi, e2e) i jak przechodzą do można MR mergować do mastera i wtedy po kolei deploy na kolejne środowiska.

Feature flag to częsta praktyka

Ok, już myślałem, że popadam w paranoję z tą parametryzacją...

Releasy mamy co 2 tygodnie chyba, że coś wymaga tego częściej i to głównie z powodu tej długiej ścieżki którą opisałem. Nie jest to dla mnie duży problem ponieważ mam dzięki temu więcej doświadczenia i jestem bardziej wszechstronny i świadomy strony biznesowej tylko brak mi obycia jak to wygląda z drugiej strony jakie wymagania musiałbym spełniać, jakie mógłbym mieć obowiazki pracując w takim pełnym zespole gdzie za każdą z tych czynności odpowiada konkretna osoba.

To masz testy tylko manualne. Warto pomyśleć dlaczego w takich przypadkach nie możesz tego zautomatyzować. Najczęściej jest to po prostu brak zestawionego środowiska testowego/lokalnego, bo np. nie potraficie dobrze zreprodukować bazy i API, które są potrzebne do testów w izolacji

W tej kwestii nie ma u nas żadnej automatyzacji chociaż przez moment były pipeline do testów to szybko zniknęły podobno te konkretne rozwiązanie co mieliśmy przestało być wspierane przez MS i tak już zostało.... Jedyne środowiska to lokalne dla nas, testowe ogólne i produkcyjne. Realnie przydał by nam się 2 branch testowy który byłby zautomatyzowany do testów nowego kodu. Obecnie releasy wyglądają tak, że kod z testu idzie na produkcje, a na teście są dodawane wszystkie dotychczasowe zmiany do testu. Jesteśmy trochę ograniczeni sprzętowo jako, że wszystko u nas stoi lokalnie.