Jak przekonać kowbojskich programistów do korzystania z kontroli źródła?

AKTUALIZACJA
Pracuję w małym zespole deweloperów, 4 facetów. Wszystkie wykorzystały kontrolę źródła. Większość z nich nie znosi kontroli źródła i zamiast tego decyduje się go nie używać. Mocno wierzę, że kontrola źródła jest niezbędną częścią rozwoju zawodowego. Kilka problemów utrudnia przekonanie ich do korzystania z kontroli źródła:

• Zespół nie jest przyzwyczajony do korzystania z TFS . Miałem 2 sesje treningowe, ale przydzielono mi tylko 1 godzinę, co jest niewystarczające.
• Członkowie zespołu bezpośrednio modyfikują kod na serwerze. Dzięki temu kod nie jest zsynchronizowany. Wymaga porównania, aby upewnić się, że pracujesz z najnowszym kodem. Pojawiają się złożone problemy z scalaniem
• Szacunki czasu oferowane przez programistów wykluczają czas wymagany do rozwiązania któregokolwiek z tych problemów. Jeśli więc powiem, że nie, zajmie to 10 razy dłużej ... Muszę stale wyjaśniać te problemy i ryzykować siebie, ponieważ teraz kierownictwo może postrzegać mnie jako „powolnego”.
• Fizyczne pliki na serwerze różnią się w nieznany sposób ponad ~ 100 plikami. Scalanie wymaga znajomości projektu, a zatem współpracy programistów, której nie jestem w stanie uzyskać.
• Inne projekty nie są zsynchronizowane. Programiści nadal nie mają zaufania do kontroli źródła, dlatego też skomplikowali problem, nie używając kontroli źródła.
• Deweloperzy twierdzą, że korzystanie z kontroli źródła jest marnotrawstwem, ponieważ scalanie jest podatne na błędy i trudne. Jest to trudny argument, ponieważ gdy kontrola źródła jest tak źle wykorzystywana, a kontrola źródła jest ciągle omijana, to rzeczywiście jest podatna na błędy. Dlatego dowody „mówią same za siebie”.
• Deweloperzy twierdzą, że bezpośrednie modyfikowanie kodu serwera, ominięcie TFS oszczędza czas. Trudno to również argumentować. Ponieważ scalanie wymagane do synchronizacji kodu na początek jest czasochłonne. Pomnóż to przez ponad 10 projektów, którymi zarządzamy.
• Pliki stałe są często przechowywane w tym samym katalogu, co projekt internetowy. Dlatego publikowanie (pełne publikowanie) usuwa te pliki, które nie są pod kontrolą źródła. Powoduje to również brak zaufania do kontroli źródła. Ponieważ „publikowanie psuje projekt”. Naprawienie tego (przeniesienie przechowywanych plików z podfolderów rozwiązania) zajmuje dużo czasu i debugowanie, ponieważ te lokalizacje nie są ustawione w pliku web.config i często występują w wielu punktach kodu.

Kultura trwa więc sama. Zła praktyka powoduje więcej złych praktyk. Złe rozwiązania zmuszają nowe hacki do „naprawiania” znacznie głębszych, znacznie bardziej czasochłonnych problemów. Serwery, miejsce na dysku twardym są niezwykle trudne do zdobycia. Jednak oczekiwania użytkowników rosną.

Co można zrobić w tej sytuacji?

To nie jest kwestia szkolenia, to kwestia czynników ludzkich. Nie chcą i tworzą blokady. Zajmij się zepsutą dynamiką grupy, jaka jest podstawowa przyczyna ich sprzeciwu - zwykle strach, czy to tylko strach przed zmianą, czy bardziej złowrogi.

Żaden profesjonalny programista dzisiaj ani przez ostatnie 20 lat nie opierał się kontroli źródła. Kiedyś, około 30 lub 40 lat temu, kiedy komputery działały wolno, kontrola źródła była jeszcze wolniejsza, a programy składały się z jednego 500-wierszowego pliku, było to bolesne i istniały ważne powody, aby go nie używać. Te zastrzeżenia mogą pochodzić tylko od najgorszego rodzaju kowbojów, o których mogę myśleć.

Czy system wymusza na nich utrudnianie życia? Dowiedz się, co to jest, i zmień system, aby unieważnić sprzeciw. Powtarzaj, aż skończysz.

Sugeruję spojrzenie na GIT lub Mercurial. Możesz utworzyć repozytorium w każdym drzewie kodu źródłowego, nawet tego nie zauważą i mogą hakować tak, jak teraz. Możesz śledzić zmiany, które włamali się do bazy kodu, zatwierdzać zmiany, łączyć je z innymi drzewami źródłowymi itp. Gdy zobaczą, że w kilka sekund połączysz wysiłek z innym produktem, mogą zmienić swoje pomysły. Kiedy stoczysz jedną z wpadek za pomocą jednego polecenia i uratujesz ich tyłek, mogą nawet ci podziękować (nie licz na to). W najgorszym przypadku dobrze wyglądasz przed bossem i, dla bonusu, sprawia, że ​​wyglądają jak kowboje, którymi są.

Połączenie wymagałoby nie tylko dużej wiedzy o projekcie

W takim razie obawiam się, że jesteś w przysłowiowym potoku bez wiosła. Jeśli scalanie nie jest opcją, nie jest też realizowane, więc mówisz, że nie możesz już dodawać funkcji, które już masz w jednej gałęzi (termin używany luźno) do drugiej.

Gdybym był tobą, ponownie rozważyłbym moje perspektywy kariery ...

Czasami problemy ze świata rzeczywistego sprawiają, że korzystanie z niego jest niepraktyczne.

Fałszywe.

Jeśli zespół nie jest przyzwyczajony do korzystania z kontroli źródła, mogą pojawić się problemy szkoleniowe

Nie ma to nic wspólnego z kontrolą kodu źródłowego i wszystkim, co dotyczy szkolenia. Szkolenie jest łatwe, tanie, wydajne i odbywa się w ciągu kilku godzin. Niezastosowanie kontroli kodu źródłowego jest kosztowne, ryzykowne, nieefektywne, a problemy utrzymują się na zawsze .

Jeśli członek zespołu bezpośrednio zmodyfikuje kod na serwerze, mogą pojawić się różne problemy.

To jest kwestia szkolenia. Jeszcze raz. Nie ma nic wspólnego z kontrolą kodu źródłowego i wszystko, co dotyczy szkolenia.

Programiści nadal nie mają zaufania do kontroli źródła, dlatego też skomplikowali problem, nie używając kontroli źródła

Muszą zostać przeszkoleni w zakresie korzystania z kontroli kodu źródłowego. Zmniejsza koszty, zmniejsza ryzyko, upraszcza rzeczy i jest bardziej wydajny. To jednorazowa inwestycja, która w każdej chwili przynosi dywidendy.

Co można zrobić w tego typu sytuacjach?

Zacznij szkolić wszystkich, jak korzystać z kontroli kodu źródłowego.

Aktualizacja

Programiści twierdzą, że bezpośrednia modyfikacja kontroli źródła oszczędza czas.

Ponieważ są w błędzie, ważne jest, aby gromadzić dane, aby dokładnie pokazać, jak to jest źle.

Niestety wydaje się, że kierownictwo nagradza natychmiastową reakcję, która w długim okresie jest kosztowna.

Jedynym sposobem na pokonanie tego systemu nagród jest

A) Zidentyfikuj, że koszt długoterminowy jest wyższy niż pozorna wartość krótkoterminowa.

B) Zidentyfikuj rzeczywiste nagrody, które faktycznie istnieją, co powoduje, że krótkoterminowe uszkodzenia (tj. Bezpośrednie zmiany) wydają się cenniejsze niż długoterminowa poprawna kontrola kodu źródłowego. Kto klepie się po głowie, że robi coś złego? Jakiego rodzaju poklepują się po głowie? Kto to daje? Aby to naprawić, musisz nazwać rzeczy, które są złe, a konkretni menedżerowie, którzy są (są) zachęcani (a)

C) Polecić zmieniony system nagród, który ceni wartość długoterminową zamiast krótkoterminowej szybkiej reakcji. Różne klepnięcia po głowie z różnych powodów.

D) Trenuj ludzi w zdobytych nagrodach za długoterminową wartość; wartość, która jest wyraźnie większa niż krótkoterminowa szybka reakcja.

Programiści, którzy nie chcą używać kontroli źródła / wersji, powinni zostać zwolnieni, to takie proste. Jak już wskazałeś, nieodłączne ryzyko i koszty NIEużywania go przewyższają wszelkie koszty ogólne ponoszone przez wiele, wiele rzędów wielkości. Każdy, kto próbuje się temu sprzeciwić, po prostu nie powinien brać udziału w tworzeniu oprogramowania, a ja stanowczo odmówiłbym współpracy z takimi ludźmi.

Najpierw rozwiązaliśmy problem, konfigurując serwer ciągłej integracji, aby wbudować kontrolę źródła w programistę. Po drugie, zablokuj dostęp do folderów tylko do odczytu, aby zapobiec obchodzeniu kontroli nad źródłami i bezpośredniej modyfikacji plików.

Jest to PITA w dni, w których nie można odtworzyć błędu lokalnie, ale poza tym przyjemniej jest pracować, zameldować się i przejść dalej, wiedząc, że zostanie automatycznie wysłany do dev przez serwer CI.

Słyszę twój ból. Wszedłem do kilku miejsc pracy, aby dowiedzieć się, że „kontrola źródła” to folder współdzielony na dysku sieciowym. Problem zasadniczo nie polega na tym, że uważają, że podejście jest lepsze niż cokolwiek innego, po prostu działa i nigdy nie zostały wprowadzone do przepływu pracy, który skutecznie integruje kontrolę źródła.

W strukturze zespołu płaskiej ziemi wyjaśniłeś, że przesunięcie zmiany z góry na dół może nie być najlepszym sposobem na zbliżenie się do sytuacji. Jedną z metod, którą warto wypróbować, jest uzyskanie wpisowego bezpośrednio od jednego lub dwóch innych deweloperów, aby koncepcja nabrała rozpędu. Gdy będziesz mieć jeszcze jednego dewelopera na pokładzie, znacznie łatwiej będzie go rozdzielić na resztę zespołu. Powoli wprowadzaj je do koncepcji, powiedzmy, zacznij pracę nad małym projektem pobocznym, uruchom go w Git , a nawet rozgałęź coś hostowanego w GitHub .

Zacznij od prostych, wprowadzaj koncepcje powoli i oddzielnie od codziennego przepływu pracy. Ludzie są świetni w uczeniu się rzeczy i dostosowywaniu się do zmian, szczególnie gdy ta zmiana zapewnia im bezpośrednie korzyści (myśl ewolucja). Jednak po przedstawieniu całej gamy małych zmian naraz staje się wyobcujący. Kiedy już zrozumieją, jak działa kontrola źródła i jakie daje zalety, spróbuj zintegrować ją z jednym z wewnętrznych projektów (jeśli rozpoczniesz nowy projekt, to zły moment na jego wprowadzenie). Pozwól innym projektom funkcjonować w istniejący sposób, jeśli ci się to podoba, będzie to szczególnie skuteczne w podkreślaniu zalet porządnej kontroli kodu.

Jeśli to się nie powiedzie, uruchom.

Oczywiście masz umiejętności techniczne, aby zidentyfikować i naprawić swoją sytuację, twoje problemy są związane z człowiekiem i procesem.

Ludzie reagują znacznie lepiej na przykład niż na widzenie, dlatego sugerowałbym „naprawienie” go samemu:

Weź kopię najnowszego źródła, przebuduj ją, aby była przyjazna dla kontroli wersji, stwórz nowy projekt z użyteczną, wybiegającą w przyszłość strukturą (dowiedz się, jak będziesz obsługiwać gałęzie, w których umieszczasz zależności innych firm itp.). Prawdopodobnie będziesz musiał to zrobić we własnym czasie.

Następnie przeciągnij współpracowników i kierownictwo do pokoju i pokaż im, jak wygląda tworzenie oprogramowania w XXI wieku. Zilustruj awarie za pomocą obecnego systemu i pokaż, jak można je wyeliminować dzięki nowej strukturze.

Będziesz musiał także ustawić się jako Strażnik Źródła - ponieważ wydajesz się, że jesteś jedyną osobą, która się tym przejmuje, to od Ciebie zależy, czy zmusisz ludzi (przy użyciu wszelkich dostępnych środków technicznych lub psychologicznych) do trzymania się plan. Upewnij się, że jedyną rzeczą, która trafia do klienta, jest maszyna kompilacji poza kontrolą źródła. Rytualnie poniżaj ludzi, którzy łamią zasady i powodują spustoszenie. Przekupić je pączkami ... cokolwiek działa.

Jeśli to wszystko wydaje się zbyt dużym wysiłkiem, to (jak powiedziano niemal w każdej innej odpowiedzi) - znajdź inną pracę. Nie są warte twojego czasu.

Krok 1 - zwolnij niekompetentnego menedżera!

Jeśli nie możesz zrobić kroku 1, spróbuj zmusić menedżera do ograniczenia wdrażania do produ tylko do skryptów pobranych z kontroli źródła. Jeśli programiści (którzy nie powinni mieć praw do produkcji na prod, zobacz krok 1, jeśli tak) chcą, aby ich rzeczy zostały wdrożone, musi pochodzić z kontroli źródła. To rozwiązało problem polegający na tym, że nie korzystaliśmy z kontroli źródła całkiem dobrze, kiedy po raz pierwszy zdecydowaliśmy się użyć jej do obsługi bazy danych, a także kodu C #.

Jak ktoś może nie chcieć różnych wersji swoich plików i widzieć różnic? Zapomnij o rozgałęzieniach i innych skomplikowanych rzeczach. Nie mają nawet podstaw. Bezpośrednie modyfikowanie pliku produkcyjnego bez dokonywania najbardziej podstawowych zmian w środowisku testowym jest szalone. Pracowałem z niektórymi osobami i na szczęście nigdy nie pracowaliśmy nad tymi samymi projektami.

Twoi współpracownicy są zbyt głupi, aby być leniwym. To strata czasu. Wszystko, co możesz zrobić, to przeszkolić swojego menedżera. Kierownictwo powinno lubić kontrolę źródła, ponieważ lubią wszystkie formy kontroli. Sprawia, że ​​czują się ważni. Pieprzyć innych; ustalenie lidera jest twoją jedyną nadzieją, ponieważ nie możesz go zastąpić. Rozpocznij pracę w sieci z innymi kompetentnymi programistami i albo spróbuj zachęcić ich do dołączenia do zespołu, gdy masz otwarcie, albo poproś ich o zatrudnienie w swoim sklepie.

To dobry przykład projektu, w którym stosowane są tak złe praktyki, że naprawienie ich staje się praktycznie niemożliwe. Naprawienie go wymagałoby zawieszenia, więc wszystko można wyczyścić bez zakłóceń. Niestety, takie projekty są zwykle (z oczywistych powodów) zbyt błędne, aby można je było zamrozić na kilka miesięcy, krytyczne błędy należy naprawiać co drugi dzień.

Możesz mieć ochotę rozwidlić projekt, aby stworzyć czystą wersję, podczas gdy brudna wersja jest traktowana tymi codziennymi poprawkami; ale najbardziej prawdopodobnym rezultatem jest to, że po kilku miesiącach, kiedy „czysta” wersja jest ukończona, nikt nie może powiedzieć, które poprawki i zmiany zostały uwzględnione od czasu rozwidlenia (ponieważ ten sam sposób myślenia, który pozwala ludziom wpaść na takie praktyki, sprawia, że ​​jest mało prawdopodobne, aby prowadzą rejestr zmian, które wprowadzają). Czysta wersja jest przestarzała, brudna wersja nadal działa, więc co się stanie? Czysta wersja została zrzucona, a słuszność okazała się słuszna.

Poza oczywistymi Znajdź nową pracę, myślę, że odpowiedź brzmi bardziej na wszystkie powyższe pytania.

Najpierw przejdź do zarządzania, aby zaangażować ich w przejście do kontroli źródła i egzekwowanie jej. Następnie przejdź do tego, co należy zrobić, aby utrzymać działanie, nawet jeśli oznacza to pracę bezpośrednio na serwerze. Rozpocznij proces uzyskiwania wszystkiego pod kontrolą źródła.

Inną opcją jest upewnienie się, że najnowsza wersja znajduje się na serwerze (co musisz zrobić niezależnie) i uruchomienie nowego repozytorium całkowicie od najnowszej. Stracisz historię, ale w tym momencie są to małe ziemniaki.

Z twojego opisu wynika, że ​​jest co najmniej jeden problem z sytuacją - zespół deweloperów wymknął się spod kontroli lub wdrożono złe rozwiązanie kontroli źródła. Tak czy inaczej, na zespole deweloperskim ciąży obowiązek użycia jakiegoś rozwiązania kontroli źródła - bezpośrednia modyfikacja kodu źródłowego w usłudze produkcyjnej prosi o pojawienie się problemów.

Z mojego doświadczenia wynika, że ​​pierwszym krokiem, który musi nastąpić natychmiast, jest zsynchronizowanie kontroli źródła z serwerem produkcyjnym. Ten krok może być tak prosty, jak pobranie kopii kodu produkcyjnego i sprawdzenie go - kod produktu jest prawdopodobnie podstawą, którą rozwija Twój zespół. Ten krok może wymagać uzupełnienia przez połączenie z kodem, który unosi się w istniejącym systemie kontroli źródła. Kod powinien przepływać od dewelopera do integracji / kontroli jakości (lub obu), a następnie do etapu lub etapu / produkcji.

Następnie zarząd musi upoważnić do korzystania z kontroli źródła. Po prostu, jeśli kompilacja nie pochodzi z systemu kontroli źródła, kod nie powinien zostać wdrożony do wersji produkcyjnej. Dostęp do produkcji musi być ograniczony tylko do zespołu wsparcia, z ograniczonym dostępem dla programistów w celu rozwiązania problemów związanych z produkcją. Programiści zazwyczaj nie powinni nigdy wdrażać gorącego kodu w środowisku produkcyjnym - na pewno mogą wystąpić problemy z produkcją, szczególnie jeśli deweloperzy są pod presją.

Zarządzanie zdecydowanie musi lepiej poradzić sobie z problemami tutaj - prawie niemożliwe będzie utrzymanie rozwoju, jeśli kod zostanie zastosowany bezpośrednio do prod (i nie przejdzie w kontrolę źródła).

Prawdziwy problem nie polega na tym, że kowboje kodujący nie używają kontroli wersji. Prawdziwy problem polega na tym, że wybrali już jakiś sposób robienia rzeczy, a ty próbujesz zmienić ich proces. Wybrany proces nie obejmuje kontroli wersji. Wszystkie zmiany procesu są trudne, chyba że sami programiści zauważą problem. Jeśli istnieje wrażenie, że istniejący system jest wystarczająco dobry, próba narzucenia innego systemu jest po prostu daremna. Jesteśmy Borg, zostaniesz zasymilowany. Oczywiście, że próbują walczyć, stając się Borg.

Dla własnego zdrowia radzę skonfigurować Git lub inny DVCS na swoim komputerze, abyś mógł śledzić zmiany. Często importuj zmiany współpracowników do swojego repozytorium. Rozwiązuj konflikty najlepiej jak potrafisz. To częściowo ochroni cię przed szaleństwem twoich współpracowników.

Wspomniałeś, że zarząd powiedział, że programiści powinni korzystać z kontroli źródła. Jeśli chcesz być zły, możesz to wymusić, sprawdzając zmiany w TFS i okresowo publikując repozytorium, blokując w ten sposób wszelkie zmiany, których nie ma w TFS. (Jeśli również utrzymujesz swój własny system DVCS, powinieneś zachować synchronizację między nimi.) Uzasadnieniem tego jest przestrzeganie rozkazów kierownictwa. Jeśli Twoi współpracownicy zmęczyli się nadpisywaniem ich zmian, zaproś ich do korzystania z TFS. I przechowuj zmiany, które nie zostały zameldowane. Kontynuuj, dopóki współpracownicy nie ustąpią lub nie zostaniesz zwolniony.

Zablokuj dowolny serwer inny niż jego rozwój. Użyj menedżera konfiguracji. Wykonuj regularnie identyfikowalne kompilacje (na podstawie tagów). Oznacz każdy zestaw zmian (tj. 1 zestaw zmian na błąd). Umieszczamy również tag na każdej kompilacji. Mieć system typu QA między deweloperem a produkcją (przynajmniej). Wykonuj kompilacje do systemu kontroli jakości przy użyciu poprawnego tagu kompilacji. Daj im żal za „złamanie kompilacji”.

Nigdy nie spotkałem się z sytuacją, w której nie mogłem odtworzyć / naprawić problemu (który pojawia się tylko podczas produkcji). Tak, spędziłem godziny, aby odtworzyć problem w systemie deweloperskim (a kiedy go odkryjesz, możesz go dodać do testu regresji).

Zrobiliśmy projekt z grupą kowbojskich kontrahentów, którzy zrobili te wszystkie złe rzeczy. Potem spędzam 4 tygodnie na sprzątaniu, a następnie stosuję powyższe praktyki. Od tego czasu projekt nie miał problemów z żadną z tych rzeczy.

Zacytować:

Zespół nie jest przyzwyczajony do korzystania z TFS

TFS okazuje się być Microsoft Team Foundation Server.

Mój pierwszy instynkt mówi: „jest to najnowsza wersja Microsoft Visual SourceSafe”

Byłbym po stronie waszych współpracowników i naprawdę sprzeciwiałbym się temu.