Subversion / kontrola źródła tylko dla kodu produkcyjnego?

Rok temu ukończyłem studia informatyczne, a teraz pracuję w małej firmie zajmującej się tworzeniem stron internetowych (ja i ​​jeden inny programista, a także menedżerowie, obsługa klienta i tester). Aż tuż przed moim uruchomieniem nie było systemu kontroli źródła. Teraz powoli zaczynamy wdrażać SVN, ale inny (starszy) programista (odtąd nazywany Joe) nalega, że ​​jedynym kodem, który powinien zostać przypisany do naszego repozytorium SVN, jest ten, który został przetestowany i zatwierdzony jako gotowy do produkcji. Oznacza to, że w większych projektach może nie być żadnych zobowiązań przez kilka tygodni lub dłużej.

Czy to normalna praktyka? Wydaje mi się, że tracimy wiele korzyści płynących z kontroli źródła, w tym:

• Dokładne śledzenie postępów projektu
• Śledzenie pojawiających się i rozwiązywanych problemów
• Łatwo wycofuj błędy
• Łatwe tworzenie kopii zapasowych kodu, dzięki czemu nie tracimy dużo, jeśli stacja robocza ulegnie awarii
• Łatwiej jest dokładnie określić, jaki kod działa w poszczególnych zakładach produkcyjnych, zakładając, że stemplujemy poprawki w plikach wykonywalnych, jak opisano tutaj
• Łatwa współpraca (chociaż nie wykonujemy żadnej pracy zespołowej; to wszystko projekty solo)
• Itp.

EDYCJA: Powinienem podkreślić, że historycznie w tej firmie nie było żadnej prawdziwej pracy zespołowej; tylko dwóch programistów pracujących nad oddzielnymi projektami. Ponadto wiele projektów jest niewielkich, więc można je zrealizować w ciągu kilku tygodni. Firma działa na rynku od ponad dekady i dobrze sobie radzi bez kontroli źródła. Projekty są zazwyczaj realizowane w przewidywanym terminie.

Jeśli projekty są ukończone w przewidywanym terminie, czy można bezpiecznie założyć, że klienci są zadowolonymi klientami? :)

Wygląda na to, że firma zaczyna również podejmować nowe rodzaje projektów i boryka się z rosnącymi bólami lub „bólami przejściowymi”. Dużo przypuszczeń, że tu się dzieje ... Proszę o wyrozumiałość!

Jeśli masz pewność, że organizacja i kontrola nad kodem może pomóc tobie i zespołowi wewnętrznie, należy rozważyć SVN, IMHO. Dostajesz punkty bonusowe, jeśli wybranie tej trasy rzeczywiście działa, a firma jest w stanie wytwarzać produkty wyższej jakości, dzięki czemu cieszą się zadowoleni klienci!

Bądź ostrożny, jeśli wydaje się, że walka z zarządzaniem stworzy napięte środowisko pracy. Faktem jest, że właściciele stworzyli firmę. I nie tylko, stworzyli odnoszącą sukcesy firmę. Jest mało prawdopodobne, że trafili w dziesiątkę, ponieważ są dobrzy w grach hazardowych.

Szanujcie, bo może się to skończyć.

Mamy nadzieję, że dzięki temu zespół będzie bardziej wydajny i szczęśliwszy. Z mojego doświadczenia trudno to uzyskać przy sfrustrowanym zarządzaniu.

Joe jest całkowicie w błędzie. Teraz możesz przedstawić argument, że masz jedną „czystą” gałąź, która reprezentuje sprawdzony, gotowy do produkcji kod. Ale nie używanie kontroli źródła, dopóki rzeczy nie będą gotowe, jest po prostu samobójcze. Jakby próbować zrobić martini bez dżinu.

„Senior” jest w rzeczywistości bardzo niewykwalifikowany. Każdy kod, który można skompilować (i przejść testy, jeśli go posiadasz), powinien zostać poddany kontroli źródła. Kontrola źródła jest centralnym zasobem do dzielenia się kodem i stopniowego budowania SW.

Dobrym punktem jest oddzielenie kodu produkcyjnego (ostatnia stabilna wersja), ale w takim przypadku systemy kontroli źródła zawierają funkcje takie jak znaczniki / etykiety i gałęzie.

Nasz zespół jest bardzo podejrzliwy, jeśli ktoś nie popełni niczego w ciągu 2-3 dni. Oznacza to, że ma on pewne problemy i być może potrzebuje pomocy. Inną kwestią kontroli źródła jest to, że zwykle jest regularnie tworzona kopia zapasowa, co nie dotyczy maszyn programistycznych. Jeśli dysk ulegnie awarii, stracisz pracę na kilka tygodni.

Odkładając na bok pytanie, czy Joe ma rację, czy źle (swoją drogą, myli się), wydaje mi się, że można osiągnąć kompromis, jeśli użyjesz rozproszonego systemu kontroli wersji, takiego jak Git lub Mercurial .

W ten sposób ty i drugi programista będziecie pracować na lokalnym repozytorium, wcześnie i często zatwierdzając zmiany w kontroli źródła, ale nie wypychając swoich zmian do repozytorium „produkcyjnego”, dopóki nie zostaną „przetestowane i zatwierdzone jako gotowe do produkcji”. Miałbyś pełną historię każdego, nad czym pracowałeś w ciągu tygodni, a Joe miałby nieskazitelne repozytorium, które zawierałoby jedynie historię zmian, które zostały pobłogosławione jako gotowe do produkcji.

To nie ma sensu, z tych samych powodów, które wymieniłeś. To jest jak używanie kontroli wersji bez korzyści wynikających z używania kontroli wersji.

Wierzę, że Joe nie zrozumiał, że systemy kontroli źródła nie są chwalebnymi kopiami zapasowymi produkcji kodu źródłowego, ale są pomocnym narzędziem dla programistów, umieszczając słowa na mniejszych etapach postępu i dojrzewania kodu dla przyszłego siebie i współpracowników. Być może Joe nie jest przyzwyczajony do pracy w zespołach z kodem innych ludzi?

Czy zastanawiałeś się kiedyś „dlaczego dodano tę linię kodu”? Znajdź zatwierdzenie, które go wprowadziło, i zobacz jego komentarz. Jeśli zobowiązujesz się tylko podczas produkcji, komentarze nie będą wystarczająco szczegółowe, aby były dla Ciebie przydatne.

Sugerowałbym również, abyś używał mocniejszego narzędzia niż SVN. Dobre wprowadzenie na temat możliwości można znaleźć na stronie http://hginit.com/ autorstwa Joela Spoelsky'ego.

Używa rtęci, a obecnie jest kilku pretendentów. Git jest uważany za bardzo potężny, a https://github.com/ ma kilka bardzo, bardzo przydatnych narzędzi i zapewnia darmowe konta startowe, dzięki czemu możesz wypróbować go naprawdę.

Joe nie wygląda tak, jakby wiedział o SVN, spróbuj dowiedzieć się o oddziałach, tagach i bagażniku ... Tagi są zgodne z tym, czego chce Joe. Niektóre czytanie najlepszych praktyk SVN nie zaszkodzi

Nigdy nie użyłem SVN, więc nie wiem, jakie byłyby procedury. Używamy ClearCase, a praktyka polega na tym, że każdy programista ma własną gałąź programistyczną, a następnie gałąź integracji, z którą łączymy się, gdy jesteśmy gotowi do rozpoczęcia testów, oraz jedną lub więcej gałęzi wydania dla zintegrowanego i przetestowanego kodu .

Joe jest hakerem, a nie programistą. Brzmi jak bardzo dobry haker, ale myli się co do tego, jak używać kontroli wersji. Co z tym zrobić?

Wydaje mi się, że Twoja organizacja zainwestowała w SVN, a kariera ograniczyłaby cię, aby rzucić wyzwanie Joe'emu i unieważnić inwestycję dolarową w serwer SVN. Skonfiguruj repozytorium GIT i użyj interfejsu git svn, aby działał tak, jak chcesz (To wszystko jest wolne oprogramowanie i jego konfiguracja zajmie godzinę dziennie, wszystko na twojej stacji roboczej). Uspołecznij swój tok pracy z Joe - może on zachować swój system przekonań o „niezanieczyszczonym repozytorium SVN” i zachować swoją wiarygodność w stosunku do drogiego białego słonia w kącie (i ego).

Za chwilę spodziewam się, że Joe spojrzy na to, jak pracujesz i zacznie robić to samo. Za rok lub dwa serwer SVN stanie się repozytorium Git.

Możesz spróbować przekonać Joe powyższymi argumentami. Jeśli to się nie powiedzie, użyj SVN lokalnie do własnych prac programistycznych i mam nadzieję, że zostanie on kiedyś odebrany przez Joe. Jeśli nie możesz ich przekonać argumentami, zrób to, o czym jesteś przekonany i pokaż im, że działa. Rodzaj podejścia rozproszonego, ale z istniejącym oprzyrządowaniem.

Powtórzę tutaj @ Carson63000 i powiem, że widziałem już takie podejście, i jest to w dużej mierze spowodowane straszliwymi możliwościami VCS do rozgałęziania / łączenia. Posiadanie gałęzi, która kompiluje i przechodzi testy, ze znacznikami dla każdej wersji, jest świetnym podejściem, ale nie należy podążać do tego stopnia, że ​​żaden inny kod nie został popełniony. DVCS w ogóle, a w szczególności git, sprawiają, że rozgałęzianie jest łatwą i powszechną operacją i zmniejsza wiele trudności z tym przepływem pracy.

Powodem, dla którego systemy kontroli wersji obsługują tagi, jest to, że możesz otagować certyfikowany kod i nadal angażować się w codzienną pracę. Ilekroć masz kod jakości produkcji, zatwierdzasz go i zrób tag. Znasz dokładny moment, w którym musisz wrócić, aby uzyskać to, co ma klient. Zawsze możesz sprawdzić i porównać różne wersje swojego kodu. W ten sposób oboje możecie być zadowoleni z tego, co macie w bazie danych kontroli źródła. Działa dla firmy, w której pracuję, która ma 100 programistów, wszyscy pracujący nad tym samym projektem. Z pewnością zadziała również dla ciebie.

Dość powszechne jest przechowywanie tylko tych elementów w systemach kontroli wersji, które są gotowe do dostarczenia do produkcji. Tak dzieje się historycznie od dziesięcioleci, ponieważ dawne czasy, gdy miejsce na dysku kosztowało setki dolarów za megabajt, a przechowywanie wszystkiego było po prostu zbyt drogie.

Nie jest to już uważany za najlepszy sposób na robienie rzeczy, ale mogę w pełni zrozumieć, dlaczego ludzie nadal to robią, ponieważ wiele starszych systemów kontroli wersji jest nadal w użyciu, co utrudnia, jeśli nie niemożliwe, wykonywanie innych czynności i nadal zachowuje wiedzę o tym, co każde wydanie jest (a raczej nie ma możliwości dowiedzenia się, co to jest wydanie, bez sprawdzania znaczników na każdym pliku, jeśli trzeba wrócić). Widziałem więcej niż jedno repozytorium, w którym jedynym sposobem na odzyskanie starego Wydanie miało pobrać z repozytorium plik zip z kodem źródłowym i plikami binarnymi dla tego wydania).