Szef jest sceptycznie nastawiony do korzystania z systemu kontroli wersji w nowym projekcie, czy powinienem mimo to?

Zobacz /software/109817/superior-refusing-to-use-subversion

Moje pytanie jest podobne, ale oto główne różnice w moim scenariuszu:

• Rozpoczynamy nowy projekt od podstaw, wykorzystując PHP i technologie internetowe. Nie byłoby przestojów w rozwoju, ponieważ przyjmowalibyśmy go od samego początku, jeśli mam na to sposób.

• Mój zespół deweloperów składa się ze mnie i mojego szefa. Jesteśmy działem „IT” stosunkowo małej firmy.

Aplikacja internetowa zastąpi starszą aplikację absolutnie bez kontroli źródła. Ze względu na różnice w geograficznych wymaganiach prawnych podjęto decyzję (zanim zostałem zatrudniony), aby podzielić aplikację na 7 całkowicie oddzielnych katalogów dla każdej wersji. Po tym czasie różni programiści robili różne rzeczy w różnych miejscach w różnych momentach. Łatowanie zmian w nich, myślę, że można to zrobić lepiej, chyba dlatego publikuję.

Propozycja mojego szefa, bezpośrednio wklejona z e-maila:

• Aktualizacje należy przesyłać jako pakiety w folderze SUBMISSIONS. Pakiet powinien zawierać wszystkie odpowiednie pliki, a także plik „UPDATE.NFO”, który zawiera opis aktualizacji, listę wszystkich dołączonych nowych plików (wraz z opisami) oraz listę wszystkich zmodyfikowanych plików ze szczegółami modyfikacji.

• Pakiety aktualizacji powinny koncentrować się na pojedynczym elemencie i nie oddalać się od zamierzonego celu. Kod powinien być zaprojektowany tak, aby był modułowy i wielokrotnego użytku, o ile to możliwe.

• Wszystkie przesłane pakiety powinny zostać zainstalowane w środowisku testowym każdego programisty wkrótce po przesłaniu. Każdy programista powinien przejrzeć nowy dodatek i wyrazić wszelkie obawy dotyczące jego instalacji w środowisku produkcyjnym. Przed załadowaniem do środowiska produkcyjnego standardowa aktualizacja pakietu powinna być przechowywana przez co najmniej 3 dni robocze dla tego procesu przeglądu. Aktualizacje / poprawki o wysokim priorytecie mogą pominąć ten wymóg.

Powodem, dla którego wymyślono kontrolę źródła, jest uczynienie tego wszystkiego automatycznym, prawda? Zasugerowałem subwersję, ponieważ tego właśnie użyłem na studiach. Szef nie lubi subwersji, ponieważ „robi bałagan w kodzie” (tzn. Używa magii binarnej i nie jest czytelny). Próbowaliśmy raz, ale myślę, że próba użycia go w systemie Windows spowodowała dziwne błędy małych / wielkich liter i nie mogliśmy sprawdzić naszych plików. Nie wiem, czy to tylko subwersja, czy wszystkie produkty kontroli źródła, które budzą zastrzeżenia.

Jaki argument powinienem przedstawić mojemu szefowi? A może ma rację i może istnieć niebezpieczeństwo utraty całej pracy z powodu jakiegoś dziwnego robaka?

Czy w ogóle się mylę? Czy kontrola źródła jest naprawdę konieczna w mojej sytuacji? To jest nasze najważniejsze oprogramowanie biznesowe, o którym mówimy, więc bez wątpienia skończy się ogromne. Ale jest tylko 2 programistów (teraz).

Dodatkowo, jeśli nie będę go w stanie przekonać, czy miałbym jakiś sens, żebym używał go tylko dla siebie? Mówię jako ktoś z bardzo ograniczonym doświadczeniem, faktycznie używający svn; wszystko, co tak naprawdę wiem, to kasa i zatwierdzanie. Jakie funkcje kontroli źródła (mogą obejmować inne produkty niż svn), które pomogłyby w moich indywidualnych wysiłkach rozwojowych?

Proszę nie komentować „dostać inną pracę”. To nie jest pomocne w debacie.

Nie pytaj go. Nie mów mu. Pokaż mu.

Zainstaluj svn, git lub cokolwiek chcesz na dodatkowej maszynie. Ćwicz używanie go sam, aż poczujesz się komfortowo, nie tylko używając go, ale wyjaśniając. Jeśli chcesz sprawić, by poczuł się swobodnie dzięki nowemu systemowi, sam musisz się z tym pogodzić. Musisz być w stanie pomóc mu łatwo dojść do siebie, gdy spieprzy scalanie lub sprawdzi coś w niewłaściwym miejscu.

Kiedy będziesz gotowy, pokaż mu dokładnie, o czym mówisz. Pokaż mu, że niczego nie „psuje”. Zwróć uwagę, że nie tylko pozwala ci to łatwo odzyskać poprzednią wersję kodu, ale także pozwala dokładnie wiedzieć, co zmieniło się między dwiema wersjami.

Zwróć uwagę, że jeśli cokolwiek stanie się z serwerem (poważny błąd, wirus, haker, awaria dysku ...) oboje będziecie wyglądać jak bohaterowie, jeśli będziecie mogli natychmiast odtworzyć niezbędną wersję. Zwróć też uwagę, że będziesz wyglądać dwa razy lepiej, jeśli będziesz w stanie wyprodukować dowolną wersję na żądanie. Wyszukaj swoją starą wiadomość e-mail i skompiluj listę problemów, które miałeś w ciągu ostatniego roku, których mogłeś uniknąć dzięki kontroli wersji.

Daj mu ściągawkę, która ułatwi mu korzystanie z twojego systemu kontroli wersji.

Na koniec zasugeruj kilka opcji, ale pozostaw decyzję . Czy powinieneś skonfigurować własny serwer, czy skorzystać z jednej z wielu hostowanych usług ? Czy powinieneś użyć svn, git lub czegoś innego? Czy należy przeprowadzić migrację wszystkich siedmiu projektów do systemu, czy najpierw wypróbować jeden lub dwa?

Korzyści z kontroli źródła wykraczają daleko poza to, że wielu programistów może pracować nad jednym fragmentem kodu. Eric Sink, założyciel SourceGear , wymienia kilka istotnych powodów, aby używać kontroli źródła jako jedynego programisty :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

Eric ma też bardzo miłe instrukcje dla początkujących dotyczące kontroli źródła . Joel Spolsky oferuje darmowy samouczek Mercurial online. Mercurial to popularny rozproszony system kontroli wersji.

W następnym kroku sugeruję, abyś zaczął używać kontroli źródła lokalnie na swoim komputerze, jako jedyny programista. Już niedługo twój szef zauważy, że jesteś w stanie opanować magię, na przykład powiedzieć w ciągu kilku minut, a nawet sekund, jak daleko sięga superkrytyczny błąd, a następnie powiesz mu dokładnie, na które konta klientów miało to wpływ i że trzeba to naprawić rozpęta się piekło. Albo będąc w stanie cofnąć wszelkie zmiany, CEO bardzo szybko się nie zgadza.

I wreszcie, zanim spróbujesz przekonać swojego szefa, możesz zagłębić się w temat rozwiązywania sporów . To 101 sprzedaży.

Jeśli się nie powiedzie - idź tak szybko, jak to praktycznie możliwe, nie marnuj czasu na pochylanie się w wiatrakach.

Tak, korzystanie z kontroli źródła, nawet jeśli tylko dla ciebie, jest całkowicie opłacalne. Na przykład Git działa naprawdę dobrze w przypadku samodzielnego programisty i pozwala wykonywać takie czynności, jak tworzenie oddziałów i łączenie (przy możliwie najniższych kosztach), a także wprowadzanie zmian w swoich wersjach.

SVN - lub jakikolwiek inny system kontroli wersji - naprawdę pozwala ci to zrobić, ale scalanie jest nieco bardziej problematyczne.

Jeśli nie uda mi się go przekonać, czy miałbym sens używać go tylko dla siebie?

Tak. Korzystanie z niego tylko dla siebie jest korzystne. Otrzymujesz historię zmian, dzięki czemu możesz zobaczyć, co jest inne.

Nie. Nie ma żadnej korzyści, ponieważ twój szef skazał twój projekt na wiele bezcelowych przeróbek, ponieważ doprowadziły do ​​zepsucia.

Bardzo polecam, jak wspomniano przed użyciem git, powodem nr 1 jest to, że każdy VCS stanowi sieć bezpieczeństwa na wypadek katastrofy. Poszukaj naklejki „W przypadku pożaru: git commit, git push, exit the building”. Kod może być przechowywany gdzie indziej, ale nie na laptopie, który może się zepsuć, zostać skradziony itp. Nawet lokalny serwer sieciowy nie jest najbezpieczniejszym miejscem na coś tak cennego jak kod.

Numer 2. Śledzenie zmian, kto, co zrobił, kiedy itp. ... Scala, Cofa. Numer 3. Zróżnicuj magiczne narzędzie dla # 2 i wielu innych przypadków. Numer 4. Oddziały Numer 5. Oznaczanie wersji, wydań itp.

Więcej informacji o jednym z najczęstszych przepływów pracy git można znaleźć tutaj: https://nvie.com/posts/a-successful-git-branching-model/

Wiem, że używanie git może początkowo budzić grozę, ale jest to dobra inwestycja dla umiejętności i obowiązkowa dla każdego zespołu programistów.

O twoim problemie z literami tekstowymi, unikaj używania Tortoise, wiem, że większość ludzi używa go jako GUI dla git, ponieważ było to bardzo powszechne w SVN, więc może to być pierwszy wybór, zamiast tego użyj wiersza poleceń lub innego GUI, takiego jak github desktop lub SourceTree z Atlasian.