Dlaczego duże firmy finansowe / ubezpieczeniowe powinny używać git i / lub github?

Pracuję dla dużego przedsiębiorstwa (30 000 pracowników) w branży finansowej / ubezpieczeniowej. Chociaż „IT” nie jest naszym głównym celem, powiedzmy sobie szczerze, są to branże oparte na informacjach, a firmy z lepszą przewagą technologiczną wydają się wyprzedzać szybciej.

W mojej firmie działa wiele zespołów programistycznych. Są na całej mapie z kontrolą wersji, nie mówiąc już o używanych językach / ramach. Niektórzy nie używają żadnych (wiem), niektórzy używają PVCS, niektórzy używają VSS, a najbardziej oświeceni używają SVN.

Chcę wprowadzić git do mojego przedsiębiorstwa. Mówiąc dokładniej, chcę wprowadzić GitHub (prywatne repozytoria). Znam odpowiednich ludzi, z którymi można o tym porozmawiać, ale bądźmy szczerzy, takie drastyczne ruchy zwykle są zastrzelone w otoczeniu dużego przedsiębiorstwa z powodu niejasnych obaw dotyczących bezpieczeństwa lub faktu, że żaden z naszych konkurentów nie korzysta z tego (i mogę powołują się tylko na jQuery, Ruby on Rails, Facebook itp.)

Więc moje pytanie brzmi: Jakie są najbardziej przekonujące powody, dla których duże przedsiębiorstwo powinno powoli i celowo przechodzić z PVCS / VSS / SVN do hostowanego rozwiązania git, takiego jak GitHub (prywatne repo). Oczywiście część mojego planu obejmuje POC dla nieistotnego projektu rozwojowego.

Jako niezainteresowana osoba trzecia mogę się martwić o kilka rzeczy. Pozwól mi więc rzucić na ciebie kilka pytań, na które lepiej przygotuj się do odpowiedzi (do swojego działu IT):

• Każda kontrola wersji jest lepsza niż żadna. Mamy wiele do wyboru, co jest z nimi nie tak?
• Rozproszona kontrola wersji? Co to jest? Jak to kontrolujemy ?
• Ile to kosztuje? Nie tylko oprogramowanie, ale także serwery, licencje, konserwacja itp.
• Nie ufam GitHub ani żadnemu zewnętrznemu hostingowi. Musimy zrobić wszystko na miejscu. Dlaczego nie możemy skonfigurować własnego serwera?
• Czy możemy uruchomić go w systemie Windows? Wiesz, musimy utrzymać go na obecnym poziomie odniesienia.
• Jak zabezpieczyć rzecz? Dostajemy SVN, ale mnie to przeraża.

To są pierwsze pytania, które się pojawią. Jeśli chodzi o VSS i PVCS, prawdopodobnie możesz wymyślić kilka dość dobrych argumentów (takich jak historia wersji VSS). SVN będzie nieco trudniejszy. Zdecydowanie polecam skupienie się na możliwościach scalania GIT, a także zalecam zachowanie otwartości na Mercurial. Każdy argument GIT jest również argumentem Mercurial - a Mercurial ma bardziej dojrzałe wsparcie dla Windows.

Bezpieczeństwo ma ogromne znaczenie dla instytucji finansowych i rządowych. Będą wyjątkowo odporne na zasoby hostowane zewnętrznie. Z punktu widzenia zarządzania ryzykiem zastanów się, co może się stać, jeśli ktoś zhakuje GitHub i ukradnie kod źródłowy lub odkryje lukę w zabezpieczeniach udokumentowaną w narzędziu do śledzenia problemów. To byłoby druzgocące dla firmy. Z czystego punktu widzenia zarządzania, jeśli firma jest legalnazobowiązany do zapłaty za każdą godzinę pracy, w jaki sposób mogą monitorować, czy pracujesz z domu, gdy zasoby znajdują się poza ich siecią VPN? Z drugiej strony, w jaki sposób mogą uniemożliwić ci szpiegostwo korporacyjne, gdy wszystkie zasoby są dostępne spoza firmy? Są to argumenty informatyczne i zarządcze przeciwko outsourcingowi hostingu. Duża firma musi patrzeć na to w ten sposób. W przypadku małej firmy patrzysz na wynik końcowy i ile kosztowałoby wdrożenie wszystkich tych usług.

Dużo taniej jest dla dużej firmy robić to w domu. Mają już zasoby informatyczne, muszą tylko trochę przesunąć obowiązki. A jeśli rozwiązanie w znacznej mierze sam się załatwi, wymagając jedynie okresowej konserwacji (kopie zapasowe i zarządzanie użytkownikami), tym bardziej powód, aby trzymać go w drzwiach firmy.

Jeśli chodzi o hosting Windows, jest to problem z organizacją. Kilka firm połknęło koolaid Windows. Inni połknęli koolaida na Linuksa. Inni rozważają to indywidualnie dla każdego przypadku. Będziesz musiał przestrzegać zasad, które dział IT ustanowił dla Twojej organizacji. Dopóki twoje rozwiązanie może być hostowane na jednym z nich, jesteś złoty.

Wreszcie w tak dużej organizacji na pewno są lennicy, którzy chcą robić wszystko po swojemu. Wszyscy mają przekonujące argumenty, dlaczego wybrali VSS, PVCS, SVN lub co masz. Dla IT wszystkie są takie same. Jedynym sposobem na konsolidację w tak dużej organizacji jest zlecenie z góry. Takie zamówienia są zawsze realizowane z oporem i prawdopodobnie Twoja firma nie chce tego robić, chyba że istnieją oczywiste korzyści z całkowitego kosztu posiadania (TCO) posiadania standardowego systemu kontroli wersji.

Pracuję również w firmie finansowej / ubezpieczeniowej (choć nie tak dużej jak ta, w której obecnie pracujesz). Mamy również wiele zespołów programistycznych i chociaż firma wybrała specjalnie produkty Microsoft do rozwoju, nadal nie ma nadrzędnej architektury, języka ani kontroli źródła. Wszyscy używamy .Net, ale mamy wiele projektów w różnych wersjach frameworku i w różnych językach. Niektóre projekty wykorzystują VSS, inne TFS. Mamy teraz nowego architekta wyższego poziomu jako menedżera ds. Kontroli jakości, który przewodził bardziej korporacyjnemu przejściu od naszego śledzenia błędów hodge-podge, kontroli źródła, użycia frameworka do bardziej uniwersalnej implementacji TFS. Jest to możliwe tylko dlatego, że jest on (a) niezwykle doświadczony w naturze oprogramowania,

Zajmując się tym we własnej organizacji, musisz najpierw rozważyć kilka rzeczy:

1. Dlaczego jesteś tak zachwycony GitHub jako odpowiedzią? Czy szukasz wspólnej kontroli źródła, czy szukasz powodu, aby wdrożyć coś, z czym czujesz się komfortowo? Nie znam odpowiedzi (i szczerze mówiąc, nie obchodzi mnie to), ale to pytanie pojawi się, gdy zaczniesz rozglądać się w interesach innych ludzi.
2. Czy jesteś obecnie powiązany z jednym z tych zespołów oprogramowania? Jeśli tak, być może będziesz musiał znaleźć niepowiązaną osobę o dobrej pozycji, aby poprzeć koncepcję. W przeciwnym razie inne zespoły programistów mogą po prostu poczuć, że próbujesz odcisnąć na nich swoje myślenie. To sprawi, że będą jeszcze bardziej odporni na tę koncepcję, ponieważ mają już coś, co działa (ich zdaniem).
3. Czy udało ci się dotrzeć do osób z innych zespołów, aby uzyskać wpisowe w koncepcję? Czy inni programiści mają podobne opinie lub obawy? Inną drogą do osiągnięcia tego jest zbudowanie masy krytycznej wśród ludzi, którzy wykonują pracę. Gdy coraz więcej osób zacznie domagać się wspólnego repozytorium źródeł, zarząd będzie musiał to zauważyć.
4. Czy znasz wystarczająco kod / procesy / wymagania innych zespołów, aby powiedzieć, że GitHub będzie dla nich (lub nie) działał?

Jeśli chodzi o twoje ostatnie (lub aktualne?) Pytanie, jedynym prawdziwym przekonującym powodem na dłuższą metę z perspektywy menedżerów jest to, że oszczędza pieniądze. Oszczędności te mogą polegać na skróceniu przestojów, zwiększonym bezpieczeństwie kodu, zwiększonej produktywności programistów, zwiększonej nadmiarowości bazy kodu (do tworzenia kopii zapasowych) itp. To, co ostatecznie będziesz musiał zrobić, to przekonać osoby, które wystawią czeki na to wszystko, że czas, wysiłek i pieniądze wydane na przejście do takiego modelu będą w końcu warte tego jako zwrot z inwestycji. Będziesz także musiał pokazać, że przyszłe wsparcie dla tego samego modelu będzie dostępne, gdy „powoli i celowo” w końcu się stanie.

Jest wiele zmian w doktrynie, więc zajmie to dużo entuzjazmu w stylu oddolnym i na pewno będziesz potrzebować kogoś na poziomie VP, aby poprzeć koncepcję. Menedżer może pracować, ale dyrektor wykonawczy będzie miał znacznie większy autorytet do nadrukowywania koncepcji na inne grupy.

Takie firmy będą chciały scentralizować swoje repozytoria. SVN, VSS i PVCS mają jedną wspólną cechę - wszystkie są architekturą klient-serwer. Git jest zaprojektowany jako rozproszony VCS i z natury jest zdecentralizowany.

GitHub - jeszcze bardziej problematyczny. To usługa zewnętrzna. Kod źródłowy w usłudze zewnętrznej jest czymś, czego kierownictwo najprawdopodobniej nigdy nie zaakceptuje.

Istnieje jednak rozwiązanie, które może zadowolić obie strony. Git ma git-svnpolecenie. Zasadniczo miałbyś repozytorium SVN, ale niektórzy programiści mogą wybrać własne lokalne repozytorium GIT i zsynchronizować je ze scentralizowanym repozytorium SVN. Dobra alternatywa dla prywatnych oddziałów lub wysyłania niezamówionych łatek. Dobra instrukcja integracji git-svn .

Kilka z tych odpowiedzi jest znacznie nieaktualnych w odniesieniu do komentarzy na temat GitHub i bezpieczeństwa z powodu zmian w GitHub od czasu ich opublikowania.

• GitHub nie zmusza Cię do hostowania na zewnątrz
• Darmo wersja GitHub, co stawia to ograniczenie w miejscu.
• Dostępna jest wersja Enterprise GitHub do wewnętrznego hostingu . https://enterprise.github.com/home . To nie jest darmowe i oczywiście kosztuje $

Firma, w której pracuję, właśnie zaczęła go używać i mieliśmy DOKŁADNE te same obawy, ponieważ nasz kod jest tajemnicą handlową, jesteśmy w sektorze finansowym. Poza tym istnieją inne sposoby korzystania z GIT, które nie obejmują GitHub, które są podobne, redmine, gitosis itp.

Odnośnie do pytania „kto go używa”: PayPal, Etsy, rackspace, vimeo, SAP, JPL NASA , jądro Linux

Przekonujących powodów technicznych jest zbyt wiele, by je wymienić. Jedyną rzeczą, na którą warto się tutaj skupić, są problemy wysokiego szczebla dotyczące dużych przedsiębiorstw, o których wspominają inne odpowiedzi. Największy, o jakim mogę myśleć, to spójność, jednolitość, przejrzysty audyt, prostota audytu. Rozwiązanie wielu problemów z wieloma innymi systemami VCS jest jednak dużym wyzwaniem.

Zmniejszono nakłady pracy we wszystkich działach, które muszą pisać różne zwariowane skrypty w celu integracji między różnymi systemami, ich audytu, raportowania i kontroli.

• Za każdym razem, gdy musiałem używać SVN w paranoicznym środowisku, takim jak firma handlowa, absurdalne haki „zgodności” i „bezpieczeństwa” były tak bardzo szkodliwe dla wydajności.

Ponieważ pochyliłem się nad kwestiami związanymi z użytkowaniem technicznym z perspektywy programisty, powiem to. Od ponad 15 lat całkowitego użytkowania korzystam z CVS, SVN, CMVC, clearcase, perforce i innych systemów w profesjonalnym otoczeniu wraz z GIT. Jeśli ktoś chciałby, żebym użył czegoś innego niż GIT (z wyjątkiem być może bzr, mercurial, perforce i clearcase (w zależności od konfiguracji dwóch ostatnich)) od razu wiedziałbym, że mój czas lepiej spędzić gdzie indziej. Już prawie doszedłem do tego wniosku (aczkolwiek rozszerzyłem niewielką ulgę na CVS i SVN) w 2009 roku. Tak bardzo miałem dość krótkich spadków korzystania z SVN w miejscu pracy, że zacząłem używać GIT jako mojego klienta SVN na początku 2010 roku pomagając nam przekonać nas do przejścia na GIT.