[mk321]

#programowanie #git #gitlab #github #pracait

Jak macie dużego taska do zrobienia, to jak to robicie?

Przykładowo task: "Dodawanie wpisów na mikroblogu".

Na pewno nie zrobicie jednego ogromnego commita, tylko podzielicie to na mniejsze części np.:
- "proste dodawanie wpisów",
- "dodanie możliwości formatowania wpisów",
- "załączanie zdjęć do wpisów (z pliku)",
- "załączanie zdjęć do wpisów z adresu URL".

Na #gerrit ( #java znają) było tak, że robiło się powiązane commity i po kolei robiło się code review (autor robił poprawki poszczególnych commitów przez amend) i wchodziły po kolei poszczególne commity.

Ale teraz robi się pull/merge requesty. Jak teraz do tego się podchodzi?

Wrzucić wszystko w jednego merge requesta?
To bardzo duża zmiana do zrobienia code review naraz i będzie długo trwało zanim wejdzie. A może ktoś by chciał już z części skorzystać. Są inne taki, które inne osoby mogłyby robić np.:
- "Powiadomienia po dodaniu komentarzy" (potrzebny przynajmniej commit: "proste dodawanie wpisów"),
- "Edytor zdjęć przy ich dodawaniu" (potrzebne 3 commity aż do "załączanie zdjęć do wpisów (z pliku)").
Poprzednie commity mogłyby wcześniej wejść, ale np. ten ostatni utknie w code review (bo będzie z nim dużo błędów) i cały merge request nie będzie zmergowany, więc przez ten cały czas nikt nie może wziąć kolejnego taska.

A może powinno się każdego takiego commita wrzucić w osobne merge requesty?
Tylko jak zrobię pierwszego commita i tylko z niego zrobię merge requesta, to jak mam dalej pracować? (Zanim wejdzie ten merge request, bo trwa code review.)
Kolejny merge request to musi być kolejny branch (muszę wyjść z tego mojego brancha, który jest jeszcze w code review). Jak powiązać tego pull requesta z poprzednim? Bo przecież jak założę nowego pull requesta z tego drugiego brancha, to będę miał tam dwa commity (bo poprzedni jeszcze nie wszedł). Jak zablokować, żeby ktoś przypadkiem nie zmergował tego przed tamtym?
I co z poprawkami do tego poprzedniego? Jak zrobię na tym pierwszym to jak zaktualizować na kolejne branche? Przy takim jednym tasku będę miał 4 branche, co mocno komplikuje.

[globalbus]

@mk321: jeśli task jest zbyt duży, to dzieli się go na mniejsze jeszcze na planowaniu. Zadania kobyły, które ciągną się przez ileś sprintów, to jest antypattern.
Traktuj pull request jako jedną zmianę, która coś konkretnego wprowadza. A jaka jest strategia przy merge, to jest do wybrania (możesz zrobić squash i skutek będzie podobny jak w gerricie).

[digupherbones]

@mk321: U nas jeśli tworzy się kolejne branche nie od developa ale od tego, co jeszcze wisi w PR, to później w tytule PR po prostu piszemy info typu feat/#002_develop (do not merge before #001). Ale generalnie ciągłe mergowanie kilku branchy jest dość upierdliwe.

[Hipodups]

@mk321: u nas to wygląda tak -> duzy task oho ktos cos zrypal, i zle opisal albo nie mial na to czasu. wiec trzeba zrobic dekompozycje. na mniejsze zadania. Taski wyceniamy na podstawie wag. wagi to kolejne elementy ciągu fibonaciego.

Zadania nie powinny miec wagi wiekszej niz 3 co oznacza ze jest sie w stanie zrobic to ponizej pol dnia roboczego. Wszystko powyzej 3 powinno byc zdekomponowane na mniejsze taski i

[mk321]

jeśli task jest zbyt duży

@globalbus: nie no task jest na tyle mały, że robi się go np. 2 dni (w sprincie masz np. 3 takie taski). Na mniejsze już ciężko podzielić (bo wtedy koszty planowania byłyby większe niż developmentu - developerzy sami ogarniają co z danego taska da się wyciągnąć, żeby innym ułatwić pracę).

Tylko jak np. 6h piszesz kod, to chciałbyś zrobić z tego osobnego commita. Żeby potem ktoś

[globalbus]

@mk321: ja rzeźbię usługi, a to się dobrze dekomponuje i tutaj rzadko ktoś wchodzi sobie wzajemnie w drogę. Albo coś jest skończone, albo nie. Nikt nie skorzysta wcześniej. Prośby o wstawianie mocków, bo komuś tam w innym zespole się tak spieszy, że biega z taczką i nie ma kiedy załadować - zlewam.

Wolę większe PR, ale spójne, bez robienia 20 mikropierdnięć. Tutaj zachodzi jeszcze patologia w niektórych zespołach, czyli biznes zatwierdzający

[mk321]

@Hipodups: pasuje mi to. Jak się tego nauczyć? Mam do tego jeszcze wiele pytań... Natrafiłeś na jakiegoś bloga lub tutorial w którym ktoś to dokładniej opisał?

Chyba że mogę cię pomęczyć ;)

wiec trzeba zrobic dekompozycje. na mniejsze zadania

Kto wtedy robi dekompozycję? Sami developerzy? Wraca do PM-a? Architekt?

jest sie w stanie zrobic to ponizej pol dnia roboczego

Super, bo długo nie wisi na code review i ludzie mają czas

[mk321]

usługi, a to się dobrze dekomponuje i tutaj rzadko ktoś wchodzi sobie wzajemnie w drogę

@globalbus: no a przykładowo model danych? Albo jakieś wspólne części (np. uprawnienia, utile np. do zapisu gdzieś np. dysk/API)?
Ktoś zaczyna swojego taska i musi pod to coś przygotować. I wiele osób potrzebuje tego (lub części). Dwa wyjścia:
- osobny task z zadaniem "technicznym"/szkieletem,
- każdy w swoim tasku robi to samo na początek i potem

[mk321]

U nas jeśli tworzy się kolejne branche nie od developa ale od tego, co jeszcze wisi w PR

@digupherbones: a jak ktoś ma zrobić poprawki w swoim commicie na CR to jak to robi?
- poprawki do commita i zrobienie amenda?
- w danym MR nowy commit z poprawkami?

Jak potem nakładasz te zmiany na swoje? Robisz pulla na czyimś branchu i potem zwykły merge na swojego? Nie ma problemów z

[Hipodups]

@mk321: o jej duzo pytan:)
jak sie tego nauczyć? Wypracowaliśmy to z zespołem bo nam tak wygodnie. PO jest byłym technicznym. na ogol on dekomponuje taski.
Czasem jest cały rys biznesowy zadania to w tedy team leader robi dekompozycje i ustala wagi. a czasem zwykli devowie jezeli maja odpowiednia wiedze w danym obszarze biznesu.

Tak.mamy jedno zbiorcze issue. Gitlab ma flagi. za pomocą flag oprocz obszarow biznesowych mozna ustalic priorytety. my

[Hipodups]

@globalbus: co do tego kiedy ma wejsc na proda dla biznesu -> feature togle polecam. wlaczasz / wylaczasz danego featura kliknieciem. a kod przed wlaczeniem moze sobie lezec nawet i pol roku na prodze w oczekiwaniu az biznes bedzie potrzebowal tego.

[globalbus]

@mk321: modele mam jednym repo i to oczywiście się robi najpierw. Inny zespół dostaje "tak to będzie wyglądać jak obkodujemy", a ty w międzyczasie spokojnie rzeźbisz.

Z mojej strony mogę polecić praktykę "steruj wszystkim konfiguracją", czyli feature-switcher. To pozwala trzymać się środowiskom niedaleko od mastera. Jak już ma finalnie zmiana wejść na środowisko, przestawiasz flagę, a potem usuwasz stary niepotrzebny kod. To upraszcza życie, zwłaszcza z niestabilnym emocjonalnie biznesem "wchodzimy/nie wchodzimy/dziś/jutro/zaraz"

[globalbus]

@Hipodups: dokładnie. Czasem przez miesiąc robimy "wdrożenia" nie zmieniając binarnie nic w kodzie ( ͡° ͜ʖ ͡°)

[mk321]

feature togle / feature-switcher

@Hipodups: @globalbus: tak, też to mamy. Albo w konfiguracji albo nawet admin po REST lub JMX może w działającej aplikacji przestawić. Przydaje się jak coś się wdroży na produkcję i okazuje się, że nie działa jak powinno. Można szybko wyłączyć i nawet nikt nie zauważy ;) Testy na produkcji najlepsze :D

[globalbus]

@mk321: plus ręczne sterowanie loadbalancerami i wdrożenia A/B
kiedyś były wdrożenia o jakiś dzikich porach, to wyłączało się połowę serwerów, wgrywało im nową wersję, a o wyznaczonej porze tylko przestawiało loadbalancing.

[Hipodups]

@mk321: dokladnie. my mamy do tego przygotowany front i mamy "fizyczne" toogle.
na froncie mozemy sobie wyklikać okresy w których feature jest dostępny, oraz role lub uzytkowny ktorzy mają dostęp.
Awaryjnie wyłączyć mozna poprzez flage w db.

No nigdy sie nie wytestuje na 100% wiec mozna wylaczyc awaryjnie, a glowna zaleta ze kod jest wydawany a nie trzymany w repo na akceptację.

[Hipodups]

@globalbus: co do "tak to bedzie wygladac jak obkodujemy" dobrze sprawdza sie wzorzec cdc consumer driven contract - ale niestety tak samo jak feature switche kksztują dodatkowy czas. Mimo to korzysci przy architekturze rozproszonej / mikroserwisow są ogromne :)

[Hipodups]

@mk321: model danych tez sie latwo dekomponuje. Migracja do db; wygenerowanie modelu i testów: napisanie seederow do bazy testowej. i juz masz 4 taski na model danych.

[globalbus]

@Hipodups: robię w szynie, więc to dokładnie pattern, który stosujemy. Każdy ma oddzielny "namespace" (w soap to realny xml namespace, w rest to url prefix). Zmiana dla jednego consumera nie zmienia nic w modelu dla pozostałych.

[digupherbones]

@mk321: > Jak potem nakładasz te zmiany na swoje? Robisz pulla na czyimś branchu i potem zwykły merge na swojego? Nie ma problemów z tym, że ktoś zrobił amenda albo dorzucił pomiędzy nowego commita? (Oczywiście poza konfliktami, bo to oczywiste.)

Tak jak piszesz, albo na bieżąco domergowanie poprawek z bazowego brancha, albo później całego developu, jeśli tamten już został wpuszczony. Ogółem nie mamy jakiegoś dużego zespołu i też raczej wszyscy ze