Ocena ilościowa zalet nowoczesnego systemu kontroli wersji [zamknięty]

Przez prawie trzy lata pracowałem jako kierownik zespołu / programista w środowisku dużych przedsiębiorstw finansowych. Nasz proces produkcji jest koszmarem, ponieważ obraca się wokół Clearcase. Mamy grupę zarządzającą zmianami, która wykonuje wszystkie wydania i która zezwoli tylko na kod, który został pobrany z produkcji.

Jedną z pierwszych rzeczy, które zrobiłem, kiedy dołączyłem, było skonfigurowanie mojego zespołu z Git. Wszyscy zgodzili się, że Clearcase jest okropny i niepraktyczny w codziennej obsłudze źródeł. Więc stworzyliśmy coś w rodzaju „nieoficjalnego” repozytorium na mojej lokalnej maszynie i napisałem skrypt, aby zsynchronizować nasze repozytorium git i Clearcase około czasu wydania.

Wieść o tym rozprzestrzeniła się na inne zespoły, a kilka z nich przyjęło ten sam proces. Używanie gita w „nieoficjalny” sposób w codziennych czynnościach i „oficjalnie” w przypadku Clearcase. Stałem się typem faceta w przypadku jakichkolwiek problemów z Git.

W tym tygodniu mam spotkanie z SVP w sprawie zmiany infrastruktury, która konkretnie chce, żebym wyjaśnił jej zalety Git. Najwyraźniej dotarły do ​​niej wieści o moich częstych narzekaniach na Clearcase. Jeśli zaakceptuje moje argumenty, będę miał naprawdę szansę, aby pomóc mojemu pracodawcy pozbyć się tej obrzydliwości.

Moje doświadczenie z menedżerami mówi mi, że a) chcą bardzo zwięzłych wyjaśnień na temat wszystkiego b) interesują się tylko faktami, które dotyczą liczb w dolarach

Deweloperowi mogę wyjaśnić zalety Git w stosunku do Clearcase (lub DOWOLNEGO innego systemu kontroli wersji w stosunku do Clearcase w tej kwestii), ale rysuję puste wyjaśnienie, jak to zrobić szefowi technicznemu bez wiedzy technicznej (ona ma MBA i zrobił jej licencjat z geografii).

Wydaje mi się, że jakikolwiek argument, który jej przedstawię, będzie albo brzmiał jak techniczny bełkot, albo że ewangelizuję moje osobiste preferencje.

To, co próbuję znaleźć, to konkretne fakty świadczące o tym, że programiści pracują efektywniej z Git lub DOWOLNYM nowoczesnym systemem kontroli źródła.

Myślę, że fakt, że inne zespoły zaczęły używać Git wewnętrznie, jest znaczącym znakiem, ale wciąż nie jest wystarczająco silny, ponieważ nadal można go odrzucić jako osobistą preferencję.

To, czego naprawdę potrzebuję, jest wystarczająco potężne, aby przebić się przez „Ten proces działał przez 20 lat, dlaczego powinniśmy go zmienić?” argument.

Byłem w bardzo podobnych sytuacjach (w przemyśle lotniczym i motoryzacyjnym). Nie spodziewaj się postępów na tym lub kolejnych spotkaniach. Obie te sytuacje przerosły moje pragnienie kontynuowania walki o poprawę, ale oto najlepsza taktyka, jaką do tej pory widziałem ...

Mówisz „ten proces działał od 20 lat”, ale czy naprawdę? Zacznij od wyjaśnienia, co masz na myśli mówiąc, że „nasz proces produkcji jest koszmarem”. Utwórz listę problemów z bieżącym procesem / narzędziem, które będą możliwie najbardziej niezależne od ClearCase.

Następnie utwórz listę „rozwiązań” procesowych / narzędziowych, które są tak agnostyczne jak Git (choć Git lub jakikolwiek nowoczesny DVCS będzie dokładnie pasował do rachunku). Wyjaśnienie, dlaczego Git jest lepszy niż ClearCase, nic nie znaczy dla osób niebędących użytkownikami.

Pozwól zespołowi infrastruktury potwierdzić, że obecne podejście ma zidentyfikowane problemy. To prawdopodobnie doprowadzi ich do zwrócenia się do IBM o pomoc w „naprawieniu” tych problemów. Pozostań w kontakcie, aby zapewnić, że IBM nie rozwiąże problemów. Ponieważ ClearCase nie ma podstawowych właściwości naszego nowoczesnego rozumienia kontroli wersji, większość z tych problemów nie może zostać naprawiona lub będzie wymagać poważnej zmiany infrastruktury.

Mamy nadzieję, że do tego momentu zespół ds. Infrastruktury uzna to za problem biznesowy, ale bez łatwego rozwiązania. W tym momencie proponujesz porównać dodatkowe rozwiązania z szacowanymi kosztami. Ponieważ wiele Twoich zespołów korzysta już z Git, powinieneś być w stanie usunąć szkolenie jako wydatek.

Powodzenia!

Nasz proces produkcji jest koszmarem, ponieważ obraca się wokół Clearcase. Mamy grupę zarządzającą zmianami, która wykonuje wszystkie wydania i która zezwoli tylko na kod, który został pobrany z produkcji.

Nie, twój proces jest „koszmarem” z powodu twojej grupy zarządzania zmianami i procedur wydawania. Śmiało i zamień Clearcase na SVN, git lub Fossil. Będziesz miał dokładnie te same problemy . (Myślę, że robią to dobrze TBH, silna kontrola uwalniania jest niezbędna).

Na tym musisz się skupić, a nie na naukowym poświadczeniu git (które są nieistotne dla wszystkich oprócz deweloperów), musisz skupić się na uzasadnieniu biznesowym, aby zmienić proces tak, aby był mniej uciążliwy. Możliwe, że możesz to zrobić za pomocą Clearcase, ale daje ci to szansę, aby w jakiś sposób podkręcić pomysł użycia git.

Jeśli nie spojrzysz na „większy obraz” tutaj, najlepszym rozwiązaniem jest użycie git z tymi samymi ograniczeniami, jakich wymaga grupa wydań. Jeśli zastanowisz się nad szerszymi aspektami kontroli zmian, docenisz ograniczenia, które musisz wprowadzić, aby git był użyteczny w rodzaju ściśle kontrolowanego procesu wydawania, jakiego potrzebuje twoja organizacja.

Kilka pomysłów dla Ciebie: spraw, by zobaczyli problemy z produktywnością obecnego systemu z punktu widzenia programisty. Zrób to jako część 1 z 2. Część 2, idź i pracuj z nimi nad wydaniem, aby zobaczyć problemy kontrolne, które deweloperzy powinni zrozumieć. Potraktuj to jako ćwiczenie edukacyjne dla obu stron, aby zobaczyć widok drugiej strony, a wtedy powinieneś być w stanie wymyślić rozwiązanie, które nadal rozwiązuje główne wymagania każdej ze stron. Zwróć uwagę, że wydania są ważniejsze od wersji deweloperskich, więc powinieneś być tym, który przygotuje się dać więcej niż się spodziewasz.

Po uzyskaniu wiedzy na temat tego, co jest wymagane do wydania, należy wyrazić zgodę na napisanie szczegółowego dokumentu procesowego (zawierającego szczegółowe informacje na temat kolejnych kroków), który można pokazać, podając mu to, czego potrzebują. Jak możesz to masować, aby strona deweloperów była dla Ciebie lepsza, zależy od Ciebie. Wyobrażam sobie, że tak naprawdę nie obchodzi ich, jak deweloper tworzy, o ile źródło jest odpowiednio zarządzane i odpowiednio wydawane - oznacza to, że będziesz musiał pokazać, w jaki sposób można powiązać zmiany kodu, aby zmienić bilety, jak pobrać kod, który stworzył wydanie do łatania, kompilowania i ponownego wydawania.

Konkretne przykłady będą bardziej niż abstrakcyjne zalety. Myślę, że odniesiesz największy sukces, jeśli potrafisz udokumentować konkretne przykłady, w których (a) Clearcase spowodował problemy, które wymagały czasu, a (b) Git rozwiązał te problemy. Pamiętaj, że nie musisz wchodzić w szczegóły techniczne, dlaczego tak jest (chyba że zostaniesz o to poproszony), po prostu pokaż, że tak jest; kierownictwo nie musi znać szczegółów technicznych, za to płacą.

Jeśli możesz dołączyć określone terminy i daty do tych przykładów, tym lepiej. Możesz również być w stanie to uzupełnić, pokazując, że zadanie X, które wykonujesz dużo, zajmuje Y minut w Clearcase i Z minut w Git.

Pamiętaj, że czas to pieniądz, więc jeśli możesz pokazać, że praca z Gitem jest szybsza , możesz pokazać, że będzie to również miało sens finansowy.

Oto próba tego, jak bym tego spróbował.

Może to zabrzmieć głupio dla dewelopera, ale dla kierownictwa zmiany technologiczne są postrzegane jako ryzykowne.

„Jeśli magia już działa, to po co ryzykować jej zniszczenie?”

Dlatego musisz obrócić stół. Zwiększ ryzyko, aby nie przejść na git. Za wszelką cenę nie sprawiaj, że będzie to nowa zabawka.

Zacznę od stwierdzenia, że ​​git jest obecnie szeroko stosowany. Użyj liczb, takich jak: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

Dla menedżera oznacza to, że powinni być w stanie znaleźć wielu programistów używających git. I cały ekosystem narzędzi innych firm (słyszałem, że nawet Microsoft integruje teraz git ze studiem wizualnym).

Poza tym menedżera nie można tak naprawdę obwiniać za przestrzeganie głównych zasad, prawda? Dla kontrastu, kto tutaj używa $ other_cvs?

Połóż nacisk na to, jak duże projekty go używają, ponieważ jest prosty, szybki, elastyczny, potężny ... Znajdź duże projekty z dołączonymi dużymi nazwami (GNU / Linux, Google, Microsoft ...), które używają git.

Po wykazaniu, że nie może to być zły ruch, możesz przejść do tego, jak poprawiłoby to sytuację w twoim przypadku.

Chcesz, aby firma pozostała konkurencyjna i aby nie wyprzedzały jej szybsze, sprawniejsze zespoły, prawda? Spróbowałbym znaleźć jakieś wewnętrzne (pisemne) oszacowania dotyczące zmiany wydajności przy użyciu Clearcase vs. Git. Możesz skorzystać z pomocy innych programistów. Następnie dokonaj ekstrapolacji dla całej firmy (tj. Wszystkich programistów), podając liczby i szacunkowy koszt pobytu w Clearcase.

Chciałbym nawet, jeśli to stosowne, podsumować całość w pisemnym e-mailu po spotkaniu (w tym odpowiednie osoby).

To, czego naprawdę potrzebuję, jest wystarczająco potężne, aby przebić się przez „Ten proces działał przez 20 lat, dlaczego powinniśmy go zmienić?” argument.

Jest to nieważny argument (powozy konne „pracowały od stuleci”, ale prawdopodobnie zamiast tego chcesz kupić samochód).

Słyszałem ten sam argument na temat svn vs. mercurial (to ja korzystałem z mercurial w moim systemie programistycznym).

Ten problem nie polega na zamianie tego, co działa; Nie próbuj tego tak wyrażać, a jeśli to jest pytanie, które musisz „pokonać”, powinieneś zacząć od wskazania, że ​​nie jest to kwestia tego, co działa, czy nie - ale kwestia tego, jakie korzyści masz z git , gdy oba działają (i dlaczego git działa lepiej).

Dobre argumenty za użyciem git:

• git jest skoncentrowany na zestawie zmian zamiast na pliku. Oznacza to, że zmiany łatwiej śledzić w różnych plikach (możliwość śledzenia w całym projekcie).

• git jest dystrybuowany zamiast scentralizowany; Oznacza to, że odprawa nie jest ograniczona szybkością sieci - znowu oszczędza dużo czasu. Oznacza to również, że nie ma ani jednego punktu awarii w przypadku awarii serwera ClearCase.

• ze względu na swój rozgałęziony system git minimalizuje potrzebę scalania (tzn. nie scalasz plików przy każdym zameldowaniu, ale przy każdej zakończonej funkcji). Przełączasz się z rozwiązywania konfliktów scalania (jeśli występują) kilka razy dziennie (przy każdym zatwierdzeniu) na raz lub dwa razy w tygodniu (przy każdej zakończonej funkcji). Oznacza to więcej czasu dla programistów (coś, co menedżerowie będą chcieli zmaksymalizować).

Myślę, że fakt, że inne zespoły zaczęły używać Git wewnętrznie, jest znaczącym znakiem, ale wciąż nie jest wystarczająco silny, ponieważ nadal można go odrzucić jako osobistą preferencję.

Możesz zauważyć, że różnica jakościowa jest tak duża , że programiści z Twojej firmy wolą komplikacje związane z instalacją, konfiguracją i używaniem git, oprócz Clearcase, ze względu na dodatkowe funkcje. W rzeczywistości jest to mocny argument (jeśli nie zapewniłby całkowicie lepszego doświadczenia użytkownika i zestawu funkcji, ludzie nie zrobiliby więcej, aby go użyć - zwłaszcza, że ​​jest to coś, czego firma nie wymaga).

W tym tygodniu mam spotkanie z SVP w sprawie zmiany infrastruktury, która konkretnie chce, żebym wyjaśnił jej zalety Git.

Narysuj wykres reprezentujący zatwierdzenia z dwoma systemami i pokaż usprawnienie uzyskane przez programistów, którzy nie biorą udziału publicznie (tzn. Jeśli rozwiążesz plik, reszta zespołu nie zostanie zablokowana i nie będzie w stanie go skompilować, dopóki go nie naprawisz). Wyjaśnij także dodatkowe kontrole jakości, które możesz wprowadzić, gdy możesz dokonywać pośrednich zmian bez wpływu na innych, fakt, że możesz uzyskać czyste różnice dla poszczególnych funkcji (niezbędne do recenzji kodu).

To, czego naprawdę potrzebuję, jest wystarczająco potężne, aby przebić się przez „Ten proces działał przez 20 lat, dlaczego powinniśmy go zmienić?” argument.

Trudno naprawdę ocenić, co byłoby dobrym argumentem, nie będąc świadkiem sceny. Ale postaram się pomóc w sformułowaniu argumentów, aby mogły zostać wysłuchane.

Zakładam, że twoi odbiorcy nie posiadają wiedzy eksperckiej na ten temat i są zainteresowani utrzymaniem obecnego kursu. Mają różne obawy i obowiązki i mogą ponieść poważne konsekwencje, jeśli coś pójdzie nie tak, więc będziesz musiał pracować z tego sposobu myślenia. Przewiduj niektóre pytania lub wątpliwości, które mogą mieć:

• Jakie nowe możliwości to przyniesie? Czy jest coś, czego obecnie nie możemy zrobić, co chcielibyśmy zrobić i na co pozwoli nam ta nowa rzecz? Zacznij od pozytywnej nuty.

• Jaki jest wpływ na harmonogramy wydań? Ile kosztuje wdrożenie tej zmiany w stosunku do najbliższej wersji? Jakie są koszty i korzyści wynikające z kolejnych wydań?

• Czy pociągnie to za sobą zmianę procesu? Czy w odróżnieniu od harmonogramu wydania zmiany będą wymagały zmiany osób w procesie wydawania? Czy będzie to dla nich przejrzyste, czy będą musieli się dostosować? Czy będziesz musiał współpracować z innymi działami? Ludzie są odporni na zmiany.

• Czy grozi niebezpieczeństwo związane z trzymaniem się obecnego systemu? Czy w obecnym procesie występują zależności oprogramowania lub sprzętu, które minęły lub wkrótce przestaną być używane? Czy opiera się na specjalistycznej wiedzy osób, które podnoszą koszty zatrudnienia? Czy ma potencjalną lukę w zabezpieczeniach, którą zatkany jest nowy system (dodatkowe punkty, jeśli dziura ta może prowadzić do działań prawnych)? Nie machaj ręką, ani „może”, ani „prawdopodobnie” tego: chodzi o to, że działał dobrze przez 20 lat, więc ciężar dowodu spoczywa na zwolenniku zmiany.

Ponadto, za szczególne o problemach i rozwiązaniach . Jeśli nie możesz znaleźć konkretnych przykładów, użyj uczciwych danych szacunkowych ze swojego stanowiska jako eksperta. Pomogą Ci przykłady innych firm / działów / podmiotów, które przyjmą taką zmianę, najlepiej z Twojej branży, oraz ich ocena tej zmiany. (Nie wybieraj przykładów, które miały jakiś upubliczniony problem informatyczny w ostatnich latach, bo spoczywa na tobie obowiązek udowodnienia, że ​​ta zmiana nie była przyczyną).

Możesz znaleźć tę odpowiedź, aby przekonać firmę, dla której pracuję, aby wdrożyć kontrolę wersji? pomocny.