Szukałem i nie mogłem znaleźć żadnych powodów biznesowych, dla których systemy git / mercurial / bazzr są lepsze niż systemy scentralizowane (subversion, perforce).

Jeśli próbujesz sprzedać DVCS osobie nietechnicznej, jakie argumenty podasz za zwiększenie zysku DVCS .

Wkrótce przekażę git swojemu menedżerowi, zajmie to trochę czasu przekształcenie repozytoriów subversion i pewne wydatki na zakup licencji smartgit.

Edytuj Próbowałem przekształcić to pytanie w ogólną dyskusję na temat scentralizowanego vs zdecentralizowanego, ale nieuchronnie zamieniło się ono w git vs. subversion. Z pewnością istnieją lepsze systemy scentralizowane niż subwersja.

Hmm, będąc menadżerem, mam dwie natychmiastowe reakcje typu „kolano”:

• Jeśli nie masz już dobrych powodów, dlaczego rzucasz gitem innym niż modnym?
• Podobnie, w jaki sposób Subversion ulega awarii, tak że potrzebujesz wymiany?

Właściwie nie jestem negatywny - myślę, że prawdopodobnie jest jakiś przypadek do zrobienia (zależny od okoliczności), ale jeśli chodzi o to, że git jest „lepszy” niż subversion, to tak naprawdę go nie masz.

Musisz także umieć wyliczyć wady - już zidentyfikowałeś koszty migracji i ponownego oprzyrządowania - co jeszcze jest problemem? np. Co stanie się z Twoim ładnym, centralnym repozytorium kopii zapasowej? Jak integrujesz się z serwerem kompilacji ciągłej integracji (jeśli go nie masz, zapomnij o git i posortuj to jako pierwsze). Och, bezpieczeństwo i śledzenie - SVN działa z odpowiednimi loginami i uprawnieniami.

Moim zdaniem korzyści płyną z elastyczności, lepszego łączenia, możliwości wykonywania lokalnych zatwierdzeń bez przerywania kompilacji i tak dalej. Wadami są brak kontroli i ta sama elastyczność.

Może być tak, że wszystko, co chcesz zrobić, to uruchomić git lokalnie na komputerze jako „lepszy” klient subversion (zamierzam to zrobić za pomocą mercurial).

Hmm, może cała ta odpowiedź jest naprawdę komentarzem? Musisz przedstawić tutaj swoją argumentację (git) w sprawie git-over-subversion (w twoim środowisku), aby sprawdzić, czy możemy pomóc ci zidentyfikować przypadek biznesowy.

FWIW, wiem, że można łatwo wyznaczyć konkretną instancję repozytorium jako źródło magistrali / źródła odniesienia, a ponadto tak łączy się z serwerem kompilacji - różnica polega na tym, że w przypadku DVCS decyzja jest bardziej administracyjna niż coś związanego z architekturą.

Powiedziałbym, że szybkie i bezbolesne rozgałęzianie i łączenie pozwoliłoby deweloperom na zwiększenie produktywności kodu, ponieważ każda nowa funkcja może zostać rozgałęziona, a następnie scalona. Sprawienie, by proces programowania przebiegał znacznie sprawniej. Ponadto rozproszony charakter pozwoliłby każdemu deweloperowi na posiadanie całej kopii kodu, więc nie ma obaw o scentralizowaną awarię serwera usuwającą cały kod. Prawdopodobnie jest więcej powodów, te dwa są jednak moimi najważniejszymi powodami używania Gita.

Zakładam, że możesz uzasadnić kontrolę wersji zwiększającą produktywność (a tym samym zysk), nawet gdy programista pracuje sam.

Dobry DVCS rozpoznaje te same korzyści w zakresie produktywności nawet podczas pracy w zespole - każdy programista może uzyskać wszystkie korzyści wynikające z pracy z kontrolą wersji - może dokonywać częstych zatwierdzeń, wycofywania zmian, bawić się rzeczami itp. - nie martwiąc się o konflikty z tym, co robią inni programiści, dopóki nie będą gotowi wypchnąć swoich zmian.

• Oddział na błąd
• Zmniejszone opóźnienie na twoich różnicach.
• Mogąc bardzo szybkiego nawigowania arbitralnie w historii oddziału podczas recenzowania.
• Nadal masz dostęp do całej swojej historii, gdy nie masz dostępu do scentralizowanego serwera: nie jesteś w biurze, po prostu wyłączyła się energia, ale bateria laptopa nadal działa, ...

Te rzeczy pozwalają pracować wydajniej, zarówno solo, jak i w zespole. Bardziej wydajna praca = krótszy czas programowania = krótszy czas wprowadzenia na rynek = zysk.

Wybacz mi link do mojego bloga, ale napisałem artykuły na ten temat:

• Dlaczego wskazówka zawsze powinna się kompilować
• Dlaczego DVCS zapewnia lepszą kontrolę centralną
• Dlaczego rozgałęzianie jest lepsze dzięki DVCS
• Dlaczego rozproszone modele rozgałęziające mogą nie działać dobrze w twoim CVCS .

Zachęcamy do głosowania, jeśli nie okażą się odpowiednie.

W skrócie, DVCS ułatwia tworzenie modeli rozgałęziających, które mogą powstrzymywać duże grupy programistów od stawiania sobie czoła, co zwiększa zarówno produktywność, jak i codzienną jakość kompilacji. Nieuporządkowana część kontroli wersji może być wykonywana w lokalnych repozytoriach, pozostawiając centralne repozytorium czystsze i wyższej jakości. Również decyzje o tym, kiedy odejść, mogą mieć duży wpływ na wydajność, na przykład, jeśli jeden dział jest gotowy do rozpoczęcia pracy nad wersją 2.0, podczas gdy inne wciąż sprzątają 1.0. DVCS pozwala na podejmowanie tych decyzji na poziomie lokalnym zamiast przez komitet.

Moje argumenty za DVCS są następujące:

• Rozgałęzienie nie jest zerwane, co prowadzi do mniejszego tarcia podczas opracowywania funkcji i utrzymywania łatanych produktów. Tarcie kosztuje pieniądze w czasie.

• Przejście na nowoczesny system lepiej przyciąga najnowocześniejszych programistów, co doprowadzi do powstania kultury lepszych produktów, która umożliwi firmie sprzedaż większej liczby produktów.

• Zatwierdzenia niesieciowe są szybsze , co pozwala programistom na częste zatwierdzanie, co prowadzi do precyzyjnego wykrywania i analizy błędów.

Zasadniczo chodzi o zmniejszenie tarcia. Jest na to określenie: Muda . Im więcej tarcia, tym bardziej bolesne jest robienie rzeczy. Im więcej bólu, tym mniej się robi, tym mniej zysków.

Przepraszam, jeśli się zgadzam, ale pozwólcie, że przedstawię uzasadnienie biznesowe w sposób niepewny:

SVN sprawia, że ​​życie programistów jest nieszczęśliwe . A to sprawia, że ​​biznes oprogramowania jest nieszczęśliwy.

... w sposób, którego wielu nie zdaje sobie sprawy, dopóki nie zacznie używać DVCS. Jest to najważniejszy przypadek biznesowy, jaki można zrobić . Czemu? Cóż, w porównaniu z kosztem znalezienia i utrzymania dobrych programistów, koszt przejścia na DVCS prawie nie istnieje .

Rozważ następujące:

• Wszystkie oprócz najbardziej trywialnych operacji w SVN (i większości innych CVCS) wymagają dostępu do sieci. W większości systemów DVCS dostęp do sieci występuje tylko podczas wykonywania operacji pushlub pull. Oznacza to, że nietrywialne polecenia są powolne . Co robisz, gdy polecenie trwa wiecznie? Gdy czekam, osobiście przeglądam wiadomości programmers.se lub hakerów. Mówiąc najprościej, DVCSes pozwalają programistom skoncentrować się na robieniu tego, co kochają: pisania oprogramowania firmy .
• SVN ma wsparcie dla rozgałęziania się w taki sam sposób, jak więzienia mają wsparcie dla upuszczania mydła pod prysznic: możesz to zrobić, ale kiedy to zrobisz, pieprzysz się. W ten sposób SVN zmusza programistów do nieustannej walki o zmiany .
• Gdy SVN jest wyłączony, jest wyłączony. Twórcom trudno jest wykonywać swoje zadania, jeśli w ogóle mogą to zrobić. W ten sposób SVN zmusza programistów do polegania na infrastrukturze w 100% wolnej od błędów .
• W dzisiejszych czasach git szybko zyskuje świadomość, podczas gdy SVN szybko ją traci. Jeśli korzystanie z DVCSes przez SVN nie przynosi żadnych korzyści, dlaczego społeczność programistów zmienia się tak szybko, jak to możliwe?

Co to wszystko oznacza? Jeszcze nie spotkałem programisty, który dostarczył DVCS uczciwą próbę, która wolałaby potem SVN. Gdybym mógł przedstawić jeszcze jedną irytującą, odważną wypowiedź, SVN jest „złem koniecznym”, z którego programiści się zmuszają. Git to narzędzie, dzięki któremu programiści są bardziej produktywni i szczęśliwsi .

(Powinienem zaznaczyć, że pogrubione stwierdzenia to te, na których powinieneś się skupić. Pozostałe zawierają jedynie kontekst).

Jedyne, o czym myślę, to to, że git działa bez połączenia sieciowego. Wszystko inne jest często trudne do sprzedania użytkownikom technicznym, którzy używają subversion lub perforce od dłuższego czasu.

Różnica pokazuje, kiedy pojawiają się problemy

Przeszliśmy na git 6 miesięcy temu po przeniesieniu naszego dziesięcioletniego repozytorium.

Do tej pory znalazłem następujące, po odrobinie eksperymentowania:

• rozgałęzianie i łączenie jest prawie bezbolesne. Ułatwia to pracę nad osobnymi funkcjami i naprawianie błędów bez wzajemnego stąpania. Ułatwia także zastosowanie danej poprawki w innym miejscu.

• bardziej solidny z założenia - nie polegasz w 100% na centralnym serwerze, który jest dostępny, a jeśli nie, możesz tymczasowo promować dowolny klon jako gorący zamiennik. Usuwa to kluczowy punkt awarii - jeśli serwer SVN ulegnie awarii z jakiegokolwiek powodu, nikt nie będzie mógł wykonywać pracy SVN. Jeśli centralne repozytorium git ulegnie awarii z jakiegokolwiek powodu, nadal możesz pracować i pchać / wyciągać lokalnie, aby upewnić się, że zatwierdzenia są replikowane. Możesz nawet mieć wiele zewnętrznych repozytoriów właśnie w tym celu.

• interakcja z repozytorium jest uproszczona. W przypadku CVS zasadniczo potrzebujesz dostępu przez cały czas, kiedy potrzebujesz jakiejś informacji. W przypadku git całe repozytorium jest dostępne lokalnie, dzięki czemu wiele rzeczy działa szybciej.

Tak więc korzyść nie jest tak duża w codziennej rutynie, ale jest bardzo wyraźna w momencie, gdy coś nie działa poprawnie!

Dlatego proponuję, aby w uzasadnieniu biznesowym sprawdzić, co zrobisz, gdy dojdzie do katastrofy ...

Łatwość rozgałęziania i łączenia jest najbardziej konkretnym powodem, ale aby przekonać kogoś, musisz dać mu konkretny przykład tego, jak to poprawia sytuację.

Załóżmy, że masz kilku programistów pracujących nad poprawą wydajności aplikacji, którzy są na etapie eksperymentalnym i nie wiedzą, czy kod, który piszą, będzie kiedykolwiek częścią gałęzi master / trunk. Muszą jednak często udostępniać sobie kod i wypróbowywać pomysły, które mogą być ślepymi zaułkami. Jak radzisz sobie z tak częstym rozgałęzianiem i łączeniem w subversion? Krótka odpowiedź brzmi: nie. Z dvcs jest to naprawdę łatwe, a programiści mogą szybko wypróbować nowe pomysły w oddziałach i dzielić się z innymi przed podjęciem decyzji, czy ten pomysł zostanie.

Podstawą biznesową dla rowów SubVersion jest wsparcie rozgałęzienia stanowiące barierę dla stabilizacji i konserwacji produktu. Jeśli chcesz wydać produkt, a następnie kontynuować rozwój, potrzebujesz oddziału. Dzięki subversion programiści nie będą używać rozgałęzień poprawnie, więc nie będziesz mógł kontynuować programowania w tunk i upewnisz się, że poprawki błędów rzeczywiście trafiają zarówno do pnia, jak i gałęzi.