Organizacja repozytorium kodu

0

Witam wszystkich,
Nie jestem pewien czy to odpowiedni dział, w razie czego proszę o przeniesienie.

Ale do rzeczy, chciałem zapytać o organizacja repozytorium. Już tłumaczę o co chodzi. Mamy zespół (3-4 os) które rozwijają system webowy. System jest w jednym egzemplarzu. A że trzeba czasem w systemie coś pilnie naprawić, albo potestować nową werjsję to wydaje mi się że należy mieć jakiś sposób jak to ma wyglądać w repozytorium. Ja mam na to taki pomysł:

w "trunk" piszemy nową funkcjonalność , jak jakieś zadanie jest bardzo duże lub chcemy sprawdzić pomysł to robimy brancha, jeżeli skończymy włanczamy do trunka.

Jeżeli zaprogramujemy wszystkie wymagane rzeczy(do nowej wersji) to kod z trunka kopiujemy do specjalnej gałęzi "test", tutaj robimy dogłębne testy i poprawiamy błędy wykryte przy testowaniu, nie wprowadzamy nowych funkcjonalności. Wiadomo też że poprawki wprowadzone w "test" powinny zostać wrzucone później również do "trunk"

Jak przeprowadzimy testy i system działa prawidłowo kopijemy kod z "test" do "prod"(w momęcie kiedy wdrażamy nową werjsę) w prod jest zawsze wersja aktualnie produkcyjna aby móc wprowadzać poprawki krytycznych błędów możliwie szybko. Tak samo tutaj poprawki powinny zostać wrzucone do "trunk", do "test" też ?

Co sądzicie żeby tak zorganizować prace? Macie może jakieś sugestie? Może rozwiązujecie to zupełnie inaczej?
Oraz pytanie bardziej techniczne, przenosząc kod do "test" i "prod" lepiej tworzyć te gałęzie od nowa czy robić merge?

Pozdrawiam.

0
tomii napisał(a)

w "trunk" piszemy nową funkcjonalność, jak jakieś zadanie jest bardzo duże lub chcemy sprawdzić pomysł to robimy brancha, jeżeli skończymy włanczamy do trunka.

Zazwyczaj każdy developer rozwija wersję "trunk"/"dev", jeśli kończy jakieś zadanie commit'uje. Robienie branchy, później ich merge może być kłopotliwe i jeśli ktoś nie umie bardzo biegle posługiwać się tą funkcjonalnością (a wiem że mimo wszystko sporo programistów ma z tym kłopot), to rodzi to więcej problemów niż to warte. Nie wiem na ile ty i twój zespół jesteście obeznani z swoim repozytorium.

tomii napisał(a)

Jeżeli zaprogramujemy wszystkie wymagane rzeczy(do nowej wersji) to kod z trunka kopiujemy do specjalnej gałęzi "test", tutaj robimy dogłębne testy i poprawiamy błędy wykryte przy testowaniu, nie wprowadzamy nowych funkcjonalności. Wiadomo też że poprawki wprowadzone w "test" powinny zostać wrzucone później również do "trunk"

Dokładnie tak. Jednak wykryte błędy poprawiałbym w trunk i promował do test. Zakładam że wersja test to takie system przeznaczony do testów zewnętrznych (UAT).

tomii napisał(a)

Jak przeprowadzimy testy i system działa prawidłowo kopijemy kod z "test" do "prod"(w momęcie kiedy wdrażamy nową werjsę) w prod jest zawsze wersja aktualnie produkcyjna aby móc wprowadzać poprawki krytycznych błędów możliwie szybko. Tak samo tutaj poprawki powinny zostać wrzucone do "trunk", do "test" też ?

Oczywiście Fixy robimy w prod i musimy spromować je w dół do test i trunk.

tomii napisał(a)

Oraz pytanie bardziej techniczne, przenosząc kod do "test" i "prod" lepiej tworzyć te gałęzie od nowa czy robić merge?

Z trunk do test robimy merge, bo teoretycznie w trunk mogą być wcommitowane (fajne słowo) rzeczy, które nie powinny iść jeszcze do test.
Jeśli test przeszło wszystkie testy pomyślnie, to teoretycznie można prod zamienić, ale dopiero po instalacji wersji test na produkcji, bo inaczej stracimy możliwość robienia fixów.

Generalnie trunk to wersja na której wszyscy pracują i mogą robić commit nawet po kilka razy dziennie, jako powiedzmy backup swojej pracy, byle nie commitować kodu, który rozwala aplikację. Na środowisko test promujemy te zmiany, które uważamy za poprawnie skończone, po jakiś wewnętrznych testach. Wg mnie test powinien nie być poprawiany, tylko rozpatrywany binarnie, tzn. OK - idzie wyżej, lub odrzucamy do poprawy.
Z klepniętego środowiska test robimy najczęściej wersję kolejnego release, często poprzednią gałąź prod odkopiowywuje się na bok, a test staje się nową gałęzią prod.

0
massther napisał(a)
tomii napisał(a)

w "trunk" piszemy nową funkcjonalność, jak jakieś zadanie jest bardzo duże lub chcemy sprawdzić pomysł to robimy brancha, jeżeli skończymy włanczamy do trunka.

Zazwyczaj każdy developer rozwija wersję "trunk"/"dev", jeśli kończy jakieś zadanie commit'uje. Robienie branchy, później ich merge może być kłopotliwe i jeśli ktoś nie umie bardzo biegle posługiwać się tą funkcjonalnością (a wiem że mimo wszystko sporo programistów ma z tym kłopot), to rodzi to więcej problemów niż to warte. Nie wiem na ile ty i twój zespół jesteście obeznani z swoim repozytorium.

Tutaj powiedziałbym że to kwestia potrzeb i umiejętności zespołu. Jenak czasem branche mogę się przydać.

massther napisał(a)
tomii napisał(a)

Jeżeli zaprogramujemy wszystkie wymagane rzeczy(do nowej wersji) to kod z trunka kopiujemy do specjalnej gałęzi "test", tutaj robimy dogłębne testy i poprawiamy błędy wykryte przy testowaniu, nie wprowadzamy nowych funkcjonalności. Wiadomo też że poprawki wprowadzone w "test" powinny zostać wrzucone później również do "trunk"

Dokładnie tak. Jednak wykryte błędy poprawiałbym w trunk i promował do test. Zakładam że wersja test to takie system przeznaczony do testów zewnętrznych (UAT).

Poprawianie w test ma tą zaletę że w trunk można tworzyć kolejne funkcjonalności (np 1 osoba poprawia błędy a pozostałe pracują już nad kolejną wersją) to wydaje się przydatne jeżeli testy z jakiś powodów się przeciągają.

Może ktoś coś jeszcze doda na ten temat?

0
tomii napisał(a)

Poprawianie w test ma tą zaletę że w trunk można tworzyć kolejne funkcjonalności (np 1 osoba poprawia błędy a pozostałe pracują już nad kolejną wersją) to wydaje się przydatne jeżeli testy z jakiś powodów się przeciągają.

Jeśli taka wersja test wypuszczana jest raz na dłuższy czas (min. co 2 mies.) i błędy nie są bardzo poważne, to przesunięcie poprawek w dół do trunk nie powinno być problemem. Jednak, jeśli taką wersję będziesz wypuszczał zbyt często (co kilka dni, tydzień) i będzie zawierała sporo błędów, bo wcześniej czy później ktoś takiego bajzlu narobi, że będziesz biegał 2-3 dni i odkręcał i rzucał mięchem po korytarzach. Nie teoretyzuje - to z obserwacji prawdziwych przypadków. Swoją drogą podobny scenariusz kilka dni temu miełem w robocie, jeden programista tak namieszał, że już drugi dzień odkręca jakieś krzywe akcje i nie wiem czy dziś się wyrobi :/

Jeszcze trochę obok tematu, ale będą to kwestie istotne z punktu widzenia procesu wytwarzania oprogramowania.

Automatyzacja build'ów. Jak na razie tylko w jednej firmie spotkałem się z profesjonalnym rozwiązaniem tego problemu. W innych robiło się to ręcznie. Nie ma problemu jak aplikacja builduje się w 1-5 min. ale jak builduje się przez 15 min. czy nawet godzinę, to już robienie tego ręcznie to jakaś padaka.
Przy użyciu ant'a (i innych tego typu, zależy jakiego jęzzyka używacie) można stworzyć sobie odpowiednie skrypty. Proponuję co dziennie z wersji trunk w nocy robić build i jeśli sie powiódł automatycznie podgrywać go jako wersję developerską, do testów wewnętrznych. Gałąź test też mogłaby podlegać automatycznym buildom, ale nie co dziennie, tylko np. jeśli zmieniło od ostatniego build coś zostało wcommitowane do tej gałęzi.

Testy automatyczne. Na etapie projektowania aplikacji warto pomyśleć nad automatycznymi testami jednostowymi, etc. Tak aby wersja test po poprawnym buildzie była od razu automatycznie walidowana, jeśli nie przejdzie testów, to jest wycofywana. Takie testy głównie powinny weryfikować jakąś logikę biznesową i inne istotne funkcjonalności używane w wielu miejscach aplikacji, czyli jakieś istotne biznesowo klasy narzędziowe.

Dokumentowanie kodu. Przy bardziej skomplikowanych metodach/klasach opisywać ich działanie, nawet z przykładami. Bo później jak ktoś ma tego użyć a nie rozumie jak, to często zaczyna pisać własny kawałek kodu, który robi to samo, czasem gorzej, z błędami. No i zasada DRY leży i kwiczy.

Sensownie dzielić projekt na biblioteki/moduły. Zawsze jest jakaś część aplikacji, która rzadko podlega zmianą (taka część core). I takie elementy powinny być odseparowane, aby zbyt wielu programistów ich nie tykało.

Jeśli tworzycie procedury skłądowane, to przyjąć jakiś schemat nazewnictwa, aby łatwo było sprawdzić czy procedura o potrzebnej funkcjonalności już jest (to samo tyczy się DAL). Bo znowu z autopsji przy większych projektach programistą nie chce się szukać czy ktoś już napisał jakąś prcedurę etc. tylko klepie jaka mu potrzebna i poźniej do pobrania podobnych danych jest kilka prcedur, chociaż możnaby stworzyć jedną czy dwie realizujące wszystkie przypadki.

W sumie powyższe wiąże się z kolejną rzeczą - komunikacja w zespole. Kiedy wszyscy członkowie zespołu wiedzą z grubsza kto czym się zajmuje, za jaki obszar odpowiada, to wiedzą kogo o co pytać. Miałem nieprzyjemność pracy w zespole, gdzie menago rozdzielał zadanka, ale w sumie nie wiedziałem co robią typy obok, więc później jak przychodziło do poprawy czyjegoś kodu, albo połączenia kilku funkcjonalności pojawiały się problemy. Ch... mnie strzelał i w końcu poszukałem innej roboty :) Codzienne 5 min. spotkania żeby każdy powiedział robie to i to i jest git mają sens, testowaliśmy to w jednej firmie i się sprawdzało. Później kierownik zaczął się lenić i coraz później przychodzić i się posypało i staneło na dłuższych spotkaniach raz w tyg., ale to też miało sens, bo każdemu dawało to całościowy obraz sytuacji w projekcie.

0

imho zbyt skomplikowane, i niepotrzebnie. Oto jak ja to widzę (ciekaw jestem innych opinii):

trunk - główne środowisko, gdzie się "Wszystko dzieje". I bugi i nowa funkcjonalność. Wszyscy pracują na trunku. Teraz załóżmy, że mamy pewną stabilną rewizję, i chcemy ją opublikować. W tym czasie należy stworzyć nowego branch'a. Branch powstał bez problemów - jest po prostu kopią trunk'a (w tym momencie). Następnie trwa proces testowania nowego release'a już na nowym branchu (nazwijmy go "test"). W tym czasie wszystkie nowe funkcjonalności lecą tylko do trunka, a poprawki do testa i są mergowane od razu do trunka.

Po pewnym czasie testowa gałąź już jest na tyle sprawna, że można ją opublikować. Nie trzeba tutaj tworzyć już nowego brancha, po co? Mamy działający test - wszelkie krytyczny fixy można na nim robić. Publikujemy branch test do tzw. live'a.
W tym momencie branch test jest zamykany.

Następny release ma nowy branch "test2" i ta sama procedura. (zamiast nazw test, test2 można oczywiście wymyślać inne, np. nazwy miast: London, Barcelona, itd..)

W ten sposób mamy jasno określone branche, które odpowiadają kolejnym publikacją.

0

"tzw live" to branch który zawiera to co aktualnie mamy na produkcji?

0
Deti napisał(a)

trunk - główne środowisko, gdzie się "Wszystko dzieje". I bugi i nowa funkcjonalność. Wszyscy pracują na trunku. [...] Branch powstał bez problemów - jest po prostu kopią trunk'a. [...] W tym czasie wszystkie nowe funkcjonalności lecą tylko do trunka, a poprawki do testa i są mergowane od razu do trunka. [...] Publikujemy branch test do tzw. live'a.

W niewielkim tylko uproszczeniu tak właśnie działamy w Wika.

Mamy trunk, z niego co tydzień jest robiony bieżący branch produkcyjny, a z tego następnie w miarę potrzeb kolejne tagi. Ten ostatni krok ułatwia i przyspiesza zarządzanie tym co dokładnie jest w danej chwili na serwerach produkcyjnych i pozwala nam się cofać do poprzedniego taga w razie problemów lub dawać zmianom zielone światło partiami.

System działa z niewielkimi poprawkami od 4 lat i mogę z czystym sercem go polecić. :) Oczywiście pewnie ma swoje wady, ale jest chyba niezłym kompromisem pomiędzy prostotą a kontrolą.

0

ale branch live też czasem wymaga poprawek, nie ma tak, że wszysto wyłapie się na etapie testów, nie przy dużej aplikacji, która w dodatku komunikuje się z kilkoma innymi systemami (pomijam kwestię że często wynika to z błędów projektowych, ale takie życie że rozwój dużych systemów działających kilka lat wymaga kompromisów)
stąd potrzeba fix'ów do live (po uprzednim testowaniu) i propagacja w dół do branchy test i trunk
w wielu firmach release nie jest co tydzień tylko co 3-6 miesięcy

ja też byłem kiedyś idealistą :) a później zobaczyłem jak się to robi w sektorze finansowym, czasem ręce opadają

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