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

62

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?

P.Brian.Mackey
źródło
24
Kluczowy element brakujących informacji: Jaka jest Twoja rola w zespole?
Morons
116
Czy życie jest naprawdę wystarczająco długie, aby tracić lata na pracę w takim miejscu? Masz zespół współpracowników, którzy nie chcą pracować w sposób kompetentny i profesjonalny, a kierownictwo to nie obchodzi. Możesz zrobić lepiej.
Carson63000,
8
O tym, że nie jest się przyzwyczajonym do kontroli źródła: jeśli jest to projekt w świecie rzeczywistym, czas przyzwyczaić się do kontroli źródła.
compman
14
Zmień miejsce pracy lub zmień miejsce pracy. Cokolwiek zdecydujesz, nie wahaj się.
Goran Jovic
11
Pomysł, że programista używał wcześniej kontroli źródła i nie kochał jej, jest prawie poza moim zrozumieniem. Może źle to wykorzystali?
jhocking 30.01.12

Odpowiedzi:

92

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

mattnz
źródło
13
-1, „Żaden profesjonalny programista dzisiaj lub przez ostatnie 20 lat nie opierał się kontroli źródła.” - totalny nonsens i całkowicie dogmatyczny. Podejrzewam, że definiujesz „profesjonalistę” jako „kogoś, kto rozwija się jak ty”.
GrandmasterB
68
@Grandmaster: Czy mówisz, że programista może nie używać kontroli kodu źródłowego, czy sprzeciwiasz się temu, że jestem zbyt dogmatyczny? Ze wszystkich rzeczy, o których myślę, że nie są otwarte na negocjacje w 2011 r., Kontrola źródła byłaby na szczycie mojej listy. Wygląda na to, że 27 innych się ze mną zgadza. Płyta DVD wypalana przy każdym wydaniu lub kopia drzewa źródłowego do folderu z datą jest prawdopodobnie kontrolą źródła.
mattnz 30.11.11
8
Mówię, że stwierdzenie, że wszyscy profesjonaliści używają kontroli źródła, jest możliwe do udowodnienia . Wiem wiele, że nie, niektórzy, którzy „stawili temu opór”. Kontrola źródła jest narzędziem, takim jak IDE. Specjaliści używają narzędzi, które ich zdaniem najlepiej nadają się do pracy. Jeśli chcą skorzystać z kontroli źródła, dobrze dla nich. Jeśli nie, to ich przywilej. Twierdzisz, że jego „brak możliwości negocjacji” jest nieistotny - nie wiedziałem, że zostałeś wyznaczony jako jedyny i ostatni arbiter tego, jak ludzie powinni pisać oprogramowanie. Osobiście nie jestem zuchwały, zakładając, że wiem lepiej dla wszystkich innych.
GrandmasterB
39
@GrandmasterB - Można domagać się praktycznie wszystkiego, zakładając, że akceptujemy niepotwierdzone dowody. Oczywiście 100% programistów nie używa kontroli źródła. Oczywiście jest przypadek lub jakiś niewielki% udanych przypadków skrajnych. Najlepszą praktyką jest stosowanie kontroli źródła. Można bezpiecznie założyć, że każdy programista, który twierdzi, że pracuje w zespole, który nie potrzebuje kontroli źródła, jest kowbojem. Nie dlatego, że kowboje nie potrafią kodować, ponieważ potrafią i często bardzo dobrze. Zwykle nie mogą współpracować z innymi, którzy również mogą.
P.Brian.Mackey
4
@MattThrower: Nawet jeśli programista pracuje sam, nadal sugerowałbym lokalną SVN. Szczerze mówiąc, jedynym „przekonującym” (tj. Jestem przekonany, że osoba podejmująca decyzję czyni to z pozycji wiedzy) argument, który kiedykolwiek słyszałem przeciwko kontroli źródła, jest następujący: „Nie wolno nam dopuszczać istnienia historii kopie naszego kodu, nawet jeśli bieżąca kopia może kiedyś zostać uszkodzona, powodując utratę całej naszej pracy ”. Nie podoba mi się ten argument, ale słyszałem, że czasami zdarza się to podczas ściśle tajnych prac rządowych.
Brian
31

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.

S.Lott
źródło
Zasugerowałem szkolenie. Wiele razy, wiele razy. Mieliśmy sesje treningowe, dwa lub trzy, ale zakończyły się niepowodzeniem. Dano mi tylko ~ 1 godzinę na ich szkolenie we WSZYSTKICH TFS. A następstwa były słabe. Dano mi stare „podążaj za marchewką”, trening nadchodzi ... ale nic się nie dzieje. Próbuję rozwiązać ten problem, ale po tylu próbach zaczynam czuć się złym facetem tylko dlatego, że jestem tutaj dziwnym człowiekiem. Powiedziałem im, co jest nieprawidłowe, ale po prostu się nie zgadzają. Zarząd mówi „tak, używaj TFS”, ale egzekwowanie wynosi 0.
P.Brian.Mackey
3
"nie udało się im". Fałszywe. Zostali podważeni przez system nagród, który nagradza złe zachowanie. Wymagane jest dalsze szkolenie. Szkolenie musi jedynie naprawić system nagród, a nie tylko wyjaśniać, jak wskazywać i klikać narzędzie.
S.Lott
1
@ P.Brian.Mackey: „Mieliśmy sesje treningowe, dwa lub trzy”. Proszę zaktualizować swoje pytanie, aby zawierał całą historię. Upewnij się, że opis jest kompletny w pytaniu. Nie wprowadzaj nowych faktów w komentarzach do konkretnej odpowiedzi.
S.Lott
1
Ok, obsesja na punkcie szkolenia jest błędna - jest to kwestia zarządzania / polityki / środowiska, której aspekt jest aspektem, ale całe szkolenie na świecie nie ma sensu, jeśli można je zignorować, podczas gdy będą się uczyć (tonąć lub pływać) niezależnie od szkolenia jeśli nie mogą zrobić nic więcej.
Murph
6
Jeden z moich kolegów z klasy VLSI wykonał tranzystor o szerokości kilku nanometrów i długości kilku mil (tak mil!), Które pasowałyby do specyfikacji. Jego odpowiedź brzmiała: „Wiem tylko, że moje gówno działa”. Miałem większą tolerancję dla ludzi w college'u. Teraz nie chciałbym skończyć z kimś takim w moim zespole. Uważam, że niektóre zespoły powinny zostać przeszkolone, a niektóre powinny być machane na pożegnanie. Życie jest zbyt krótkie, by nienawidzić pracy / kolegów.
Job
17

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.

papka
źródło
10

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.

CaffGeek
źródło
Dobra sugestia, w rzeczywistości świetna. Ale kierownictwo dało mi czerwone światło na CI. Brak funduszy na maszynę wirtualną lub serwer fizyczny. Nie ma też czasu na konfigurację.
P.Brian.Mackey
7
Środki na serwer CI? Finansuje się. W razie potrzeby pokaż, ile czasu zajmuje ręczne wdrożenie wideo. Następnie wyjaśnij, że robi się to kilka razy dziennie. Czasem kilku programistów. I powinien zwrócić się w zaoszczędzonym czasie w ciągu miesiąca.
CaffGeek
6
Do diabła, uruchom Jenkinsa na własnej maszynie.
Matthew Flynn
5
+1 za zablokowanie struktury folderów. Zdejmij od nich uprawnienia serwera i będą musieli podążać właściwą drogą (poprzez kontrolę źródła)
Mauro
8

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.

Kim Burgess
źródło
Też myślę, że gdy programiści popadają w samozadowolenie z powodu opóźnień, zwykle postępują zgodnie z aksjomatem „jeśli to nie jest zepsute, nie naprawiaj go”. Większość miejsc, w których pracowałem, miała tę samą mentalność kowbojską, ponieważ 1. ponieważ istnieje duża luka w umiejętnościach komputerowych między programistami i ich menedżerami lub 2. jest tak niewielu programistów, że nie ma hierarchii umiejętności, lub starszy pracownik w ich firmie oznacza „Pracowałem 10 lat, robiąc te same rzeczy, które zrobiłem na pierwszym”.
Chris C
2
Udostępniony folder sieciowy z kopią w tle jest formą kontroli wersji. Z pewnością bardzo kiepska forma, ale mimo to jest jedna.
Joeri Sebrechts,
4
Zawsze pytam, jakiego systemu kontroli kodu źródłowego używa podczas wywiadu. Kiedy CTO jednej firmy powiedział „Co to jest”, uciekłem.
Zachary K
6

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.

MarcE
źródło
lol, dobre sugestie. Większość tego już zrobiono. Menedżer mówi „tak, musimy użyć kontroli źródła”. Ale zespół nie używa kontroli źródła. Mówię kierownikowi, a mgr po prostu mówi „tak, musimy go użyć”. Nikt się nie skarcił. Bez egzekwowania.
P.Brian.Mackey
3
@ P.Brian.Mackey - Czasami musisz po prostu przejść wszystkie BOFH . Kiedyś pojechałem na wakacje, a pracujący dla mnie kontrahent spędził cały tydzień surfując po witrynach randkowych. Kiedy wróciłem i odkryłem to, na jego komputerze pojawił się niewytłumaczalny problem z dostępem TCP / IP, którego nie byłem w stanie rozwiązać. Niech twój szef odbierze im prawa do hakowania bezpośrednio na serwerze i zmusi ich do przejścia przez TFS w celu wdrożenia, a wkrótce wyczyszczą swoje działania lub zrezygnują, niezależnie od tego, czy wygrasz.
Mark Booth
Pomysł Keeper of the Source jest dobry. Możesz poprosić ich o przesłanie ci ich zmian - lub przynajmniej poinformować cię, że coś zrobili i zaktualizować twoje repo z diff za pomocą prod. Lub uruchom fswatchi poproś o zatwierdzenie repozytorium po zmianie plików.
Joe McMahon
4

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

HLGEM
źródło
4

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.

JeffO
źródło
3

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.

użytkownik 281377
źródło
2

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.

Jacob Schoen
źródło
2

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

JW8
źródło
1

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.

tp1
źródło
1

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.

Jonathan
źródło
0

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.

Paweł
źródło
-3

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.

Niels Basjes
źródło
1
Team Foundation Server to zupełnie inna bestia niż SourceSafe. Porównanie nie jest uczciwe.
pap.
Rdzeń mojego argumentu ma bardzo niewiele wspólnego z TFS. Podstawowym problemem jest historyczny brak korzystania z jakiejkolwiek kontroli źródła.
P.Brian.Mackey,
Czy wiedzą, że jest inaczej? Ja nie.
Niels Basjes,
@Hiels Basjes - Czy wiedzą, co jest inne?
P.Brian.Mackey,
Ten TFS różni się od Bezpiecznego źródła.
Niels Basjes,