Uzasadnienie biznesowe dla zdecentralizowanych systemów kontroli wersji


26

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.


1
Jesteśmy w podobnej sytuacji, jeśli chodzi o robienie sprawy i trzeba powiedzieć, że nie jestem przekonany, że taka jest obecnie.
Jon Hopkins,

Czy może git-svnspełnić twoje potrzeby?
JBRWilkinson

@JBRWilkinson Właśnie użyłem git-svn do migracji kilku repozytoriów do git. Firma nie zainwestowała zbyt wiele w narzędzia integrujące się z svn, więc nie było większego problemu.
Keyo

Odwołaj się do edycji - wciąż nie wyjaśniłeś, jak i dlaczego SVN zawodzi, tak że uważasz, że potrzebujesz wymiany. Moja odpowiedź (na przykład) NIE dotyczy git vs svn, ale dotyczy znalezienia uzasadnienia biznesowego dla zmiany status quo.
Murph,

Odpowiedzi:


23

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ą.


1
Rozwiązanie problemów związanych z uprawnieniami / elastycznością: nadal potrzebujesz repozytorium „źródłowego”, w którym możesz faktycznie ustawić prawa jak zwykle. Ciągła integracja działa dla repozytorium źródłowego, programiści klonują repozytorium źródłowe itp. Jego kopia zapasowa jest jednak mniej ważna, ponieważ każdy ma klon, a nie tylko kasę.
Matthieu M.

1
Wskazanie na to, że pełne klony są kopiami zapasowymi, jest dobrze wykonane. Przyznam się swobodnie, że są pewne obszary, których nie rozumiem wystarczająco dobrze, ponieważ moje „prace” są svn, a mój merkurial jest osobisty i, jak dotąd, nieco ograniczony.
Murph,

14

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.


2
W środowisku biznesowym „serwer scentralizowany” miałby nadmiarowość, kopie zapasowe i administratorów odpowiedzialnych za utrzymanie go (i wszystkich innych serwerów) przy życiu.
JBRWilkinson

2
W dużym środowisku biznesowym nadmiarowość serwerów. W małej firmie taka redundancja serwerów nie jest taka pewna.
Michael Shaw,

2
Scentralizowana awaria serwera nie spowodowałaby usunięcia całego kodu. Nawet jeśli nie masz kopii zapasowych, najgorsze, co można zrobić, to usunąć historię zmian. Ale tak długo, jak wszyscy programiści mają wypisany kod, istnieje on również w obecnej formie w swoich systemach.
Mason Wheeler,

1
@mason: ale to całkiem założenie: „tak długo, jak wszyscy deweloperzy ...”. Ponieważ w małych firmach z jeszcze mniejszymi projektami projekty mogą żyć i są używane z radością bez nikogo kodującego przez rok lub dwa
Inca

A także nie doceniłbym wartości historii popełnień. W ogromnym systemie bardzo cenne może być sprawdzenie, kto i dlaczego coś zrobił w kodzie.
Tamás Szelei

8

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.


Właśnie to zamierzałem zamieścić. Z pewnością powinieneś zobaczyć poprawę produktywności od programistów wcześnie i często do własnego repozytorium, bez powodowania żadnych problemów dla któregokolwiek ze współpracowników.
Carson63000,

5
Wtedy będziesz w piekle integracji, kiedy w końcu wprowadzisz zmiany. To źle, a nie dobrze.
Henry

Ponieważ wykonujesz programowanie lokalne z dużą ilością zatwierdzeń, możesz nadal pobierać zmiany z centralnego repozytorium i utrzymywać lokalne zmiany zgodnie z ciągłym rozwojem, nad którym pracują inni. Dlatego gdy przyjdzie czas, aby wprowadzić zmiany do centralnego repozytorium, powinieneś już mieć większość zmian, które tam się miały, a integracja będzie łatwa.
DaveJohnston,

1
Chyba że jeden z twoich współpracowników zrobił dokładnie to samo i oboje nie zintegrowaliście się przez jakiś czas. Zawsze jest kompromis. Widziałem przypadki, w których rzeczy zostały zintegrowane na głównej linii, gdzie nie powinny być (złe rozwiązanie, ślepa próba rozwiązania i tym podobne), integracja przy kompletności funkcji ma również swoje zalety.
Joppe,

2
Czy nie możesz zrobić wszystkich tych rzeczy z (a) oddziałami SVN lub (b) wieloma kopiami roboczymi?
JBRWilkinson

4
  • 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.


3

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

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.


Twoje wpisy na blogu są dobrze napisane. Jednak nie przeczytałem jeszcze ich wszystkich. Zastanawiam się, dlaczego wybrałeś Bzr, kiedy Git i Hg wydają się być znacznie bardziej popularne. Ludzie nienawidzą Bzr za powolność. Jestem także fanem Gita z powodu skrótów drzew zamiast numerów wersji, co wydaje mi się bardzo bezpieczne. Czy liczby obrotów BZR nie zostaną rozszyfrowane, gdy gałęzie zostaną połączone?
Keyo

2
@Keyo, wybrałem BZR, ponieważ musiałem uczyć DVCS dla siebie, a BZR jest najbardziej przyjazny dla początkujących. Od tego czasu przerzuciłem się na git pod względem szybkości, funkcji i stabilności. Bazaar również aktualizuje swoje wersje i ma unikalne na całym świecie identyfikatory, po prostu nie są one domyślnie udostępniane użytkownikowi. Ich numery wersji są naprawdę nie różni się od korzystania HEAD~1, HEAD~2itp w git. Bardzo rzadko potrzebujesz rzeczywistego skrótu, ale jest to pierwsza rzecz, której uczysz się w git i zawsze masz przed sobą twarz. Ukrywanie tego przed użytkownikiem, chyba że naprawdę go potrzebujesz, jest jednym z powodów, dla których bzr jest bardziej przyjazny dla początkujących.
Karl Bielefeldt,

Dziękuję za wyjaśnienie. Git nie był dla mnie łatwy, pochodzący z subwersji. Wiele poleceń ma to samo słowo, ale robi różne rzeczy.
Keyo

2

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.


2

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).


5
-1 - jesteś znakomity i chociaż w tekście jest trochę prawdy, jest tak negatywnie obrócony, że przesuwa się raczej w stronę FUD niż uzasadnionej analizy. Czy SVN jest wolny? Tylko jeśli repozytorium jest rozległe, a sieć lodowcowa. Czy SVN przestał działać - nie pamiętam, żeby kiedykolwiek był wyłączony, i NIE, ponieważ mój komputer nie zależy od istnienia repozytorium do edycji / kompilacji / uruchomienia źródła. Czy rozgałęzianie i łączenie SVN jest złe? Wow, ludzie mają krótkie wspomnienia ... dlaczego DVCS zyskuje dostęp do myśli? Miszmasz funkcjonalności - która została ulepszona - i, szczerze mówiąc, moda.
Murph,

1
@Murph - Czy ci się to podoba, czy nie, ludzie nienawidzą zmiany do tego stopnia, że stają się obrzydliwi . Aby przekonać ich do zmiany, musisz przekonać ich, że status quo jest zepsuty. I jest zepsuty. FUD jest zły tylko wtedy, gdy nie ma powodu do obaw, niepewności i wątpliwości. Jeśli chodzi o udostępnianie myśli, zgadzam się z tobą. Ale tak naprawdę nie o to chodzi. To, czy ludzie, którzy podejmują decyzje, zgadzają się z tym. I każdy menedżer, którego spotkałem, był przekonany tym argumentem (nawet jeśli nienawidzi gita).
Jason Baker

2
Niekoniecznie nie zgadzam się z tobą, Jason sugeruje tylko, że twoje punkty nie są dobrze uzasadnione. W szczególności uważam, że przesadzasz z efektem, a jeśli zostaniesz przyłapany na tym, tracisz punkty za argument, nawet jeśli masz rację. (Z wyjątkiem punktów, w których oczywiście się mylisz ... (
:)

2
Wszystkie twoje punkty dotyczą raczej opinii niż faktów. Wymienię każde, ale w komentarzach nie ma wystarczająco dużo miejsca. A może odpowiesz jeszcze raz bez udziału?
Henry

1
@Henry - Programmers.se służy do subiektywnych pytań i odpowiedzi. Subiektywny == kwestia opinii.
Jason Baker

1

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.


2
Jasne, ale Subversion działa głównie bez połączenia sieciowego. (Nie popełnianie oczywiście, ale typowe rzeczy, takie jak uzyskiwanie informacji o kopii roboczej lub różnicowanie się z wersją bazową, wszystkie prace.)
j_random_hacker

@j_random_hacker: Celem VCS jest śledzenie zmian w kodzie. Zatwierdzanie zmian kodu śledzenia. Jeśli nie możesz zatwierdzić offline, argumentowałbym, że twój VCS nie działa w trybie offline.
Daenyth

1

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 ...


Jest to ten sam argument, co w przypadku kopii zapasowych: Potrzebujesz ich tylko w przypadku katastrofy. Pytanie brzmi, co zrobisz, kiedy to się stanie, i co wtedy zaakceptujesz.

0

Ł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.


-1

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.