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


21

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.


2
Jak przy okazji motywuje ten pomysł? Jeśli nie podał ci żadnych powodów, pytałeś?
Anto

8
Czy „Joe” rozumie Rozgałęzienie? Niektóre delikatne pytania, które można znaleźć, mogą być interesujące.
James

2
@Anto - myślę, że najlepiej to podsumować: „to nie jest produkcja i nie powinno być częścią repozytorium produkcji”.
Pan Jefferson

1
@James - Nie sądzę, że on zna SVN ogólnie bardzo dobrze, więc nie, nie sądzę, że on wie o rozgałęzianiu. Ale biorąc pod uwagę poniższe odpowiedzi, myślę, że to jest rozwiązanie.
Pan Jefferson

4
Przeczytaj to pytanie i mały głos w mojej głowie krzyczał „NOOOOOOOOOOOOOooooooooooooooo”.
Kevin D

Odpowiedzi:


1

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.


42

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.


6
Podkreśl problem rozgałęziania i tagowania. To - jak sądzę - ważna funkcja, która powoduje, że ludzie nalegają na produkcję wyłącznie w SVN.
S.Lott

3
doskonały punkt, nawet z twoim nastawieniem do wódki.
Covar

Dosyć? Powiedziałbym, że się myli. Bez pytania.
Steven Evers

2
@Covar: Nie zanieczyszczam wódki wermutem :)
Wyatt Barnett

22

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


12
Ale nie ma umiejętności pracy jako członek zespołu.
Ladislav Mrnka

2
@Tom Hamming: Cięcie kodu nie rozwija oprogramowania. Jestem pewien, że jest dobry w programowaniu, ale obecnie kontrola wersji nie jest już „narzędziem”, podobnie jak IDE. Jasne, technicznie możesz się bez niego obejść, ale nikt przy zdrowych zmysłach nie robi tego.
Steven Evers

2
@SnOrfus - Chociaż w pewnym stopniu zgadzam się co do użyteczności SCM, moim celem w tym pytaniu nie jest zniesławianie Joe i / lub jego umiejętności programistycznych. Znów okazuje się, że jest świetnym produktem, jest kompetentny i radził sobie bez SCM przez ostatnie 10 lat. Moim celem w tym pytaniu było sprawdzenie, czy jego perspektywa była szeroko rozpowszechniona, z którą po prostu się nie spotkałem; W końcu jestem po prostu ze szkoły i jestem stosunkowo niedoświadczony w tej branży. W każdym razie uważam, że naprawdę chce zapewnić jakość i niezawodność przepływu pracy.
Pan Jefferson

3
@Tom: Mogę ci teraz powiedzieć, że bez względu na to, co myślisz o jakości jego pracy, nie jest on wykwalifikowanym programistą, jeśli nie wie, jak właściwie korzystać z kontroli źródła. Nie ma innej opcji poza tym, że może pracował sam w piwnicy. Nawet w moich własnych projektach, w których jestem jedynym programistą, używam kontroli źródła w pełnym zakresie.
Jordania

5
@SnOrfus: Mogę pracować bardzo szczęśliwie bez IDE. Nie będę działać bez kontroli wersji. Jeśli zespół go nie używa, uruchomię go na własną rękę.
kevin cline

12

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.


1
Zastanowiłem się nad tym i przeprowadziłem trochę dochodzenia (i usłyszałem dobre rzeczy), ale waham się z tym, że mamy już zakupiony i zainstalowany serwer VisualSVN i żadne z nas nie ma doświadczenia z Git ani Mercurial . To będzie jeszcze trudniejsza bitwa, jeśli spróbuję przekonać wszystkich, że musimy kupić więcej oprogramowania i / lub wyrzucić istniejącą inwestycję. Ale dobra uwaga.
Pan Jefferson

3
@Tom: Jeśli musi to być Subversion na zapleczu, możesz użyć warstwy interoperacyjności Gitta lub Mercuriala Subversion dla rzeczy, które nie są gotowe do produkcji, i pchnąć pracę w subversion, gdy będzie gotowa.
Ken Bloom

2
@Tom Hamming: Przełączam się z SVN na GIT prawie rok temu. Po kilku przekleństwach zacząłem go kochać (chociaż pod Cygwinem nie działa tak dobrze jak pod Linuksem). Nigdy nie wydałem na to żadnych pieniędzy, jestem całkiem zadowolony z wiersza poleceń i dwóch darmowych narzędzi. Nawet nie pracuję nad integracją go z moim IDE (eclipse). YMMV, ale gdybym był na twoim miejscu, skorzystałbym z mojego prywatnego repozytorium git i git svndo interakcji. Nie musisz nic kupować i nikogo nie musisz przekonywać; nawet nie muszą wiedzieć.
maaartinus

1
@Tom Hamming: Jako indywidualny programista możesz regularnie git pushwprowadzać zmiany na innym komputerze (jako kopia zapasowa). Nie musi to być repozytorium „master”.
Greg Hewgill

1
@Tom Hamming: Trzymanie się SVN, ponieważ kupiłeś i zainstalowałeś serwer SVN, to naprawdę błędny koszt. Git i Mercurial są bezpłatne, a koszt VisualSVN został już zapłacony, więc spójrz na swoje opcje, ponieważ każda z nich ma taki sam (zerowy) koszt początkowej konfiguracji.
Cercerilla

7

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.


5

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


3

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


2

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 .


SVN też może to zrobić.
Phil Lello,

2

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.


inwestycja dolara w serwer svn byłaby nie większa niż inwestycja dolara w serwer git repo ...
TZHX

2

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.


2

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.


1

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.


0

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


Ciekawe, że należy pamiętać, że uwzględniono pliki binarne. Osobna dyskusja, którą mamy, dotyczy tego, czy włączyć skompilowane pliki binarne do kontroli źródła. Mówię „nie”, ponieważ marnuje miejsce i oznacza, że ​​możesz wyczyścić kasę po prostu przez kompilację. Dlaczego historycznie skompilowano pliki?
Pan Jefferson

pliki binarne zostały uwzględnione, ponieważ niemożliwe było wiarygodne odzyskanie źródeł wydania. Pliki binarne były więc przechowywane na wypadek, gdyby kiedykolwiek były potrzebne do przywrócenia serwera do starszej wersji ... Kompromis oparty na złych decyzjach podjętych wiele lat wcześniej.
jwenting
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.