Jak przekonac git-flow hejterów w projektach z zewnętrzną baza danych

Odpowiedz Nowy wątek
2019-05-10 15:00
0

W nowej pracy trafił mi się ciekawy projekt, który został niedawno zmigrowany na githuba.
problem polega na tym, że common practice to jest checkoutowanie lokalnie mastera i pushowanie doń zmian. <cringe>
Przy samym projekcie pracuje z kilkudziesięciu devów rozproszonych po całym świecie.
Cześć dinozaurów oprogromowanie żyją ciągle w SVN-owym mindsecie.

Chciałbym podrajvować ten temat w firmie, bo czemu nie.
myślę, ze to bedzie miało korzyść dla każdego.

ale im bardziej analizuję temat znajdujący się w naszej domenie, tym więcej pytań, a mniej odpowiedzi.

Sprawa polega na tym, że do kazdego releasu jest folder ze skryptami SQLowymi, które roszerzają bazę danych o jakieś columny albo dodają wartości lub procedury. Spotkałem to już w kilku firmach. Codziennie rano baza danych na podstawie sqli z mastera się rekonstruuje.

no i teraz rozkmina, jak mozna to zaimplementować do git-flow, żeby nie było to tak upierdliwe, że zmiany deweloperskie na jednym branchu, a zmiany w bazie danych na drugim i radosne pushowanie do mastera?

bardzo łatwo się rozsynchronizować, a z drugiej strony skypty restorujące sa odpalane poprzez jakiegoś bata, który jest wywołuje po nazwie.

Moim marzeniem byłoby, żeby kazdy miał lokalnie schemat bazy danych, ale niestety przy rozwoju oporogramowania często potrzebne są jakieś dane do pracy, choćby sprzed kilku miesiący z produkcji czy jakieś spreparowane dla DEVów.

Pozostało 580 znaków

2019-05-12 01:20
3
Gworys napisał(a):

A co jest takiego złego w Git Flow.? Czy to taka różnica, czy merg'ujesz do mastera czy branch'a develop?

No, jeśli czyjaś praca kończy się na mergowaniu do jednego brancha, to nie. Ale na poziomie projektu wciąż trzeba synchronizować developa z masterem i odwrotnie, a to dodatkowa, zbędna robota, która nie daje żadnej wartości dodanej. Więc po co to robić?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Pokaż pozostałe 2 komentarze
Automatycznie przez skrypty, tak sobie to wyobrażam – dopóki nie ma konfliktów. - Silv 2019-05-12 15:57
No ale skąd skrypt wie, kiedy ma nastąpić synchronizacja, i jak rozwiązać konflikty? - somekind 2019-05-12 19:14
Właśnie konfliktów nie rozwiązuje; a kiedy, to nie wiem; tak tylko przypuszczam. - Silv 2019-05-12 21:59
Trochę mi to przypomina rozmowę z zarządem: - Potrzebujemy 4 GB do serwera, żeby mógł obsłużyć nowych klientów - A teraz nie umie obsługiwać nowych klientów? - Umie - No to &uja a nie RAM dostaniecie. - Ale niedługo przestanie! - Wy też, zwalniam was. Tak się kończą próby wytłumaczenia, że jednak jakaś rzecz się przyda. - Lubię Naleśniki z Dżemem 2019-05-12 22:08
@Lubię Naleśniki z Dżemem: :D Tak, wiem, nie mam argumentów. - Silv 2019-05-12 22:11

Pozostało 580 znaków

2019-05-12 02:05
0

w ogóle śmiesznie, bo z jednej strony jest modne git-flow, a z drugiej strony mamy inną modę - continuous integration, które często jest nie do osiągnięcia w git-flow (nie to, żeby git-flow tego zabraniał, ale helou, jeśli ficzer brancze, się powoli integrują z developem, a develop jeszcze wolniej z masterem (kiedyś pracowałem w zespole gdzie merdż to developa trwał kilka tygodni, a do mastera to już w ogóle jeszcze dłużej, od święta tylko), to nie ma mowy o żadnej continous integration.

Ale z drugiej strony czytałem kiedyś artykuł, który w sposób błyskotliwy wyśmiewał w ogóle ideę mastera i merdzowania do jednego centralnego mastera. Wg tego artykułu to Gita powinno się używać w sposób bardziej P2P, że Alice merdzuje do Boba, a potem Bob merdzuje do Charliego, i w końcu wczesniej czy później się pomerdżuje wszystko (eventual consistency), ale no nie wiem. Może taki sposób jak opisywali to byłby dobry w jakichś dużych rozproszonych teamach open source, ale jak jest kilka osób w zespole to wydaje mi się, że raczej powinno się dążyć właśnie do tego, żeby każdy kawałek kodu był jak najszybciej zintegrowany, bo tak łatwiej jak wszyscy mają aktualny obraz całości i mogą działać dalej.

Czyli więc rozgałęzianie się (i czerpanie wolności z tego, że wszystko jest bardziej distributed, podzielone na gałęzie itp.) czy bardziej ciągłą integracja? To pierwsze brzmi bardziej cool (much distributed, wow), ale tak z doświadczenia to wolę to drugie.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 2x, ostatnio: LukeJL, 2019-05-12 02:13
Może się nie znam, ale ta idea P2P brzmi jak szaleństwo - mad_penguin 2019-05-12 03:23

Pozostało 580 znaków

2019-05-12 02:54
0
somekind napisał(a):
Gworys napisał(a):

A co jest takiego złego w Git Flow.? Czy to taka różnica, czy merg'ujesz do mastera czy branch'a develop?

No, jeśli czyjaś praca kończy się na mergowaniu do jednego brancha, to nie. Ale na poziomie projektu wciąż trzeba synchronizować developa z masterem i odwrotnie, a to dodatkowa, zbędna robota, która nie daje żadnej wartości dodanej. Więc po co to robić?

Przecież i tak najwięcej będzie synchronizacji z feature i develop. Zaletą jest to, że masz bundle tematyczne. Master to tylko taki historical branch.

Jaką formę workflow możesz w zamian polecić?


Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Exception' not found.
edytowany 1x, ostatnio: Gworys, 2019-05-12 02:54

Pozostało 580 znaków

2019-05-12 03:12
1
Gworys napisał(a):

Przecież i tak najwięcej będzie synchronizacji z feature i develop.

Najwięcej synchronizacji jest między dev a master.

Zaletą jest to, że masz bundle tematyczne. Master to tylko taki historical branch.

No ten sam efekt osiągam mając jedynie mastera, więc jakoś nie widzę tej zalety.

Jaką formę workflow możesz w zamian polecić?

Feature branche mergowane do mastera + tagi na oznaczenie releasów.

Umie ktoś powiedzieć, jaki konkretnie problem rozwiązuje git-flow?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2019-05-12 03:16
Normalny flow jest za mało korporacyjny i przez to nieczytelny dla managerów, którzy potrzebują "wyraźną drabinkę" ;) - hauleth 2019-05-12 13:42
No właśnie ostatnio się mile zaskoczyłem. Na retro nowi w zespole rzucili pomysł wdrożenia git-flow, to nawet PM im powiedział, że to niczego nie wnosi i nie ma sensu. ;) - somekind 2019-05-13 02:07

Pozostało 580 znaków

2019-05-12 06:48
2

Dobry pomysł, wróćmy do podstaw jakie problemy rozwiązują feature branche ?

Najważniejszy problem to izolacja kodu w trakcie developmentu od kodu już gotowego przed użytkownikiem:

  • feature branche, robią to statycznie na etapie budowy
  • feature toggle, robią to dynamicznie na etapie wykonania

Pozostało 580 znaków

2019-05-12 14:54
2
neves napisał(a):

Najważniejszy problem to izolacja kodu w trakcie developmentu od kodu już gotowego przed użytkownikiem

Feature branche służą do organizacji pracy developera. Feature toggle służą do udostępniania ficzerów użytkownikom. To są dwa zupełnie różne aspekty. Jeśli ktoś próbuje ich używać zamiennie, to znaczy, że wrzuca brudną bieliznę do lodówki.

Problemy rozwiązywane przez oddzielne branche to chociażby:

  • syf w historii (wymieszania commitów dotyczących różnych ficzerów);
  • brak potrzeby wielokrotnego rozwiązywania konfliktów (których będzie tym więcej, im więcej będzie commitów do głównej gałęzi);
  • większa wolność, elastyczność i wygoda dla programisty.

Czyli generalnie wszystkie problemy, które są tworzone przez scentralizowane systemy kontroli wersji.

No i tak ogólnie, to ideą przewodnią Gita jest praca z gałęziami. Jeśli ktoś nie używa gałęzi w Gicie, to działa w sposób bezsensowny, zupełnie tak jakby pchał samochód zamiast nim jechać.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Pokaż pozostałe 10 komentarzy
@somekind: nie zauważyłem takiej sugestii, ale jeśli skoro jest, to chyba nie jest wiążąca dla całego wątku. - Silv 2019-05-13 23:47
Ja tam nie wiem, ale jak ja chciałem napisać o gałęziach lokalnych, to użyłem sformułowania "gałęzie lokalne". - Lubię Naleśniki z Dżemem 2019-05-14 06:22
@Lubię Naleśniki z Dżemem: ale masz na myśli gałęzie lokalne u użytkownika, w przeciwieństwie do remote, tak? - Silv 2019-05-14 06:23
@Silv: Tak. Chodzi o to, że w Git mam kontrolę nad tym, co siedzi u mnie, jako programisty a jest na serwerze. Mogę sobie zrobić 20 commitów z tekstem "dupa dupa" i tylko ja będę wiedział o co chodzi, a do serwera wypchać tylko te, które są czytelne i coś wnoszą. Tzn. bezpośrednio ciężko wybrać commity do wrzucenia, ale coś w tym stylu da się zrobić. Dzięki temu w masterze na serwerze mam tylko jeden commit o nazwie w stylu "Dodana obsługa protokołu XMPP". Jeszcze na serwerze mam feature branch z poszczególnymi etapami realizacji. A lokalnie mogę mieć tony historii zmian. - Lubię Naleśniki z Dżemem 2019-05-14 06:31
Tak, w Gicie jest ogromna kontrola nad historią zmian. Tyle, że zaproponowano tu podejście całkowitej jej utraty i pracy tylko na masterze. Czyli nie możesz mieć feature branchy. To, że branch robisz lokalnie, nie zmienia faktu, że jest feature branchem. - somekind 2019-05-14 12:09

Pozostało 580 znaków

2019-05-12 20:14
0

Problemy rozwiązywane przez oddzielne branche to chociażby:
brak potrzeby wielokrotnego rozwiązywania konfliktów (których będzie tym więcej, im więcej będzie commitów do głównej gałęzi);

Ja to bym powiedział, że jest właśnie odwrotnie. Dla przykładu: jest sporo out-of-tree patches do Linuksa. Trzeba je co jakiś czas rebase'ować na najnowszą wersję Linuksa, bo pojawiają się konflikty. Natomiast, gdy patch zostanie zmerge'owany do głównej gałęzi to konflikty dotyczące tego patcha znikają, bo kolejne zmiany w Linuksie biorą już pod uwagę najnowszy kod, gdzie patch jest zintegrowany.

No i tak ogólnie, to ideą przewodnią Gita jest praca z gałęziami. Jeśli ktoś nie używa gałęzi w Gicie, to działa w sposób bezsensowny, zupełnie tak jakby pchał samochód zamiast nim jechać.

Prace nad Gitem rozpoczęły się po tym, jak BitKeeper, używany wtedy do rozwoju Linuksa, przestał być darmowy dla projektów o otwartym kodzie źródłowym. Torvalds szukał rozproszonego systemu kontroli wersji, który mógłby być użyty zamiast BitKeepera, głównymi kryteriami wyboru były:

  • Przykład CVS, czego nie robić.
  • System powinien być rozproszony.
  • System powinien być chroniony przed błędami w repozytorium (przypadkowymi, jak awaria twardego dysku, jak i złośliwymi, wprowadzonymi przez kogoś).
  • System powinien być szybki.

Nie widzę tutaj brandzlowania się branchami. To trochę tak jakby powiedzieć - ideą przewodnią OOPa jest dziedziczenie, więc dziedziczmy przy każdej okazji.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Najlepiej to nie dodawać żadnych commitów do mastera, tylko wszystko wrzucać squash'em w rebase do jednego commita. :D - Gworys 2019-05-12 20:42
Można też podsyłać sobie tarballe jak to się kiedyś w świecie Linuksa robiło :p - Wibowit 2019-05-12 20:45
@Gworys: jeden commit na cały projekt... mam chyba zbyt bujną wyobraźnię. ;) - Silv 2019-05-12 22:21
Commit-as-a-service - Wibowit 2019-05-12 22:22
Bo to "Commit Development" :D - Gworys 2019-05-12 23:02

Pozostało 580 znaków

2019-05-12 20:35
0

Ale patche to co innego, niż jako takie workflow.

Czy Git Flow wymusza robienie wszystkiego na oddzielnym barnchu.?
Jak mam 3 bugi to nie lepiej jest zrobić trzy commity na innym branchu.?


Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Exception' not found.

Pozostało 580 znaków

2019-05-12 20:55
0

Ludzie nie kumają Gita i dlatego są takie dyskusje. Git daje możliwość robienia burdelu w lokalnym repo a porządku w centralnym. A że ktoś robi odwrotnie...

Pokaż pozostałe 2 komentarze
@Lubię Naleśniki z Dżemem: rozumiem. Nie wiem, czy chcę być tak nazywany... ;) - Silv 2019-05-12 22:27
@Silv: Też nie wiem, czy chcesz być tak nazywany. Ale może modek zmieni ci nick jak będziesz grzeczny :) . - Lubię Naleśniki z Dżemem 2019-05-12 22:31
@Lubię Naleśniki z Dżemem: czytaj wątek przed pisaniem postów i trzymaj się zasad kultury w stosunku do rozmówców. - somekind 2019-05-13 02:11
@somekind: Napisz od razu gdzie nie trzymałem się zasad kultury. Nie lubię podchodów. - Lubię Naleśniki z Dżemem 2019-05-13 06:51

Pozostało 580 znaków

2019-05-12 21:05
1

Ale patche to co innego, niż jako takie workflow.

Wydaje mi się, że w środowisku Linuksowym patch i branch to w zasadzie pojęcia bliskoznaczne. Brancha nie wrzucisz bezpośrednio na listę mejlingową do review, ale serię patchy wygenerowanych z commitów już tak. Jakkolwiek by tego nie nazwać, to jednak sprawa z konfliktami pozostaje ta sama - im szybciej wrzucisz zmiany do głównej gałęzi, tym mniej będzie konfliktów. Oczywiście przy założeniu, że te twoje zmiany nie są tymczasowe i nie zechcesz ich całych w niedługim czasie odkręcić.

Co do feature switchy - jest to przecież standardowa praktyka w IT. Jak się pogrzebie w ustawieniach programów to się znajdzie miljon feature switchy. W typowym biznesowym projekcie feature switchy jest zwykle bardzo mało, bo nie opłaca się utrzymywać dwóch sposobów na robienie tego samego, bądź np przedstawiania tych samych danych na dwa różne sposoby. W typowym biznesowym projekcie jest jedna jedyna słuszna wersja każdego feature'a.

Bardzo bliskim feature switchom zagadnieniem jest wersjonowanie API np RESTowego. Żeby udostępniać dwie wersje RESTowego API - starą i nową - trzeba mieć trochę zduplikowanego kodu w głównej gałęzi, identycznie jak przy feature switchach. Owa duplikacja kodu jest powodem dla którego programiści nie chcą robić ani feature switchy, ani wersjonowania API.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Xenu Link Sleuth (3x)