Przejście do kontroli źródła

Nasza jest dość małą firmą (3-4 programistów i 3-4 projektantów stron), która opracowuje jednozadaniową aplikację internetową PHP, która zapewnia funkcjonalność dla ponad 100 stron internetowych. Działamy od kilku lat w oddzielnym środowisku programistycznym i produkcyjnym, które działało dość dobrze. Zawsze istniało wystarczająco dużo oddzielnych funkcji, aby programiści nigdy tak naprawdę nie kolidowali i wygodniej było pracować bez kontroli źródła; mimo że wiązało się to z ryzykiem utraty danych i mieliśmy dość dużo plików, które zaginęły w przypadkowym ruchu.

Innym aspektem jest to, że nasi projektanci nie znają się na technologii (wprowadziłem je do znaczników HTML zamiast używania WYSIWYG). Był to jeden z powodów, dla których wahał się przejść do wersji.

Jednak teraz, gdy dotarliśmy do ponad 100 witryn i zespół programistów się powiększa, staram się ujednolicić nasze procedury, a kontrola źródła wydaje się logicznym krokiem, jeśli chodzi o programistów. Mam nadzieję, że przyspieszy to także wdrażanie łatek.

Niestety mam bardzo ograniczone doświadczenie w konfigurowaniu systemu kontroli źródła. To, co ciekawi mnie od osób o podobnej konfiguracji, lub doświadczenia związane z przełączaniem:

1) Czy wersjonujesz wszystko (strony, css, szablony HTML i kod aplikacji), a tym samym zmusza projektantów do nauki wersji? A może tylko programiści pracują nad kodem aplikacji?

2) Na jakie pułapki trzeba uważać przy początkowej konfiguracji kontroli źródła?

3) Wdrażanie dev => porad produkcji dla kontroli źródła.

Dzięki za wgląd.

Edycja 1: Dang. Jak dotąd wszyscy zalecają kontrolowanie wszystkiego. To sprawi, że wcześnie stracę włosy. Prawdopodobnie w najbliższej przyszłości wywołają nowe pytanie. Dzięki za dotychczasowe porady, nie przestawaj!

Edycja 2: Wiele dobrych odpowiedzi, a my przyjrzymy się różnym systemom kontroli wersji. Dzięki za odpowiedzi wszystkim!

Dobrze jest mieć wszystko w wersji, nawet dla projektantów. A jeśli dobrze wdrożone przy dobrym szkoleniu, myślę, że będą one bardziej pomocne niż uciążliwe.

Jeśli dopiero zaczynasz, zdecydowanie sugeruję użycie rozproszonego systemu kontroli wersji, takiego jak git lub mercurial . Jest to ogólny trend na świecie i ma wiele zalet. Łatwo jest pracować w trybie rozłączonym, bez zależności sieci i możliwości wykonywania prywatnej, niepolerowanej pracy, wciąż pod kontrolą wersji, sprawdzając wszystko centralnie, gdy jest gotowy.

I nie uciekaj się do odwołań do władzy lub czegokolwiek, ale sprawdź, co Joel Spolsky ma do powiedzenia na ten temat . (Wybór cytatu: „Subversion = Pijawki. Mercurial i Git = Antybiotyki.”) Interesująco wskazuje na to, że te nowe systemy wykorzystują nowy model mentalny, inny niż tradycyjna kontrola wersji - dlatego właśnie wchodzimy w tego rodzaju podejście od samego początku to zwycięstwo.

Powiedziałbym, że poddaj wszystko kontroli wersji. Gdy wszystko zadziała, możesz skopiować go do znacznika, który dla większości systemów SCM nie wymaga dużej ilości miejsca na dysku na serwerze.

Jeśli chodzi o początkowe pułapki, nie powinieneś się martwić; przekaż wszystko serwerowi, a jeśli nie jest poprawne, możesz je przetasować i usunąć dodatkowe rzeczy później. Jedyne, czego bym nie popełnił, to artefakty zbudowane ze źródła, tj. Pliki kodu java należą do kontroli wersji, ale nie skompilowane klasy lub całe ISO / DVD z plików binarnych „zbudowanych ze źródła”.

Opracowanie produkcji jest łatwe, na każdym ważnym etapie tworzenia oddziału. Układ katalogu w systemie kontroli wersji zwykle wygląda mniej więcej tak:

/ trunk / projekt / oddziały / projekt / wersja1 / oddziały / projekt / wersja2 / oddziały / projekt / wersja3

Powiedzmy, że znajdziesz błąd w wersji 2 produktu, przejdź do tej gałęzi, napraw ją i wypuść wersję 2.1. Cały czas pracujesz nad folderem / trunk / project dla nowej wersji 4 i od Ciebie zależy, które funkcje zostaną połączone do tyłu i do przodu.

Nie pozwól, by pijacy z SCM oszukiwali cię, istnieją bardzo niewielkie różnice funkcjonalne między popularnymi systemami kontroli wersji, a mianowicie Subversion i Git. Najważniejsze dla Twojego zespołu będzie to, jak dobrze te serwery integrują się z istniejącymi narzędziami. Nie lubię też WYSIWYGów, ale na pewno miło jest mieć Eclipse-php lub inne IDE kompatybilne z serwerem.

Jestem programistą i byłem wcześniej zaangażowany w pracę jako administrator IT.

Aby odpowiedzieć na konkretne pytania:

1) Tak, wersja wszystko.

2) Zaproponuj skonfigurowanie repozytorium fikcyjnego repozytorium kontroli i projektu fikcyjnego dla osób, które mogą się uczyć.

3) Oznacz wersje, które zostaną wprowadzone do produkcji. nawet próby. Następnie zawsze możesz sprawdzić konkretną wersję uruchomioną przez kogoś.

Widzę, że otagowałeś pytanie CVS.

Sugeruję, aby zamiast tego poważnie przyjrzeć się subversion, w połączeniu z TortoiseSVN, co czyni go bardzo łatwym w użyciu. Istnieje również TortoiseCVS.

Sugeruję uruchomienie wewnętrznego samouczka na temat kontroli wersji. Będę zaskoczony, jeśli twoi programiści / projektanci nie spotkali się z tym wcześniej. Żółw sprawia, że ​​jest bardzo przyjazny dla użytkownika.

Korzystne może być również zainstalowanie jednego z interfejsów sieciowych w cvs lub subversion.

Powodem, dla którego sugeruję subwersję w stosunku do CVS, jest to, że chociaż CVS jest bardzo dobry, ma poważne problemy z projektowaniem i implementacją. Biggies były dla mnie: 1) Nie można wersjonować katalogów 2) Obsługa plików binarnych nie jest zbyt dobra, ponieważ wiele rzeczy domyślnie jest tekstem. 3) Brak zobowiązań atomowych. 4) Pamiętam, że często psuje i pozostawia pliki blokujące, które musiałem ręcznie usunąć ze sklepu z kodami. Było w tym miejsce miejsce na korupcję, ponieważ twoje pliki blokujące. 5) Obsługa protokołu SSL i zarządzanie użytkownikami / hasłami

Subversion w zasadzie naprawia wszystkie te problemy to prawdopodobnie wiele innych. Ma również wiele zaawansowanych funkcji, takich jak zewnętrzne (z których faktycznie korzystam). Możliwe jest także połączenie użytkowników / grup w Active Directory, co może okazać się przydatne. W tym czasie korzystałem z CVS, który nie był dostępny. Być może teraz nie sprawdziłem.

Prawdopodobnie największą różnicą w używaniu svn jest to, że nie tworzysz tagów. Zamiast tego tworzysz kopie, które wyglądają na kopie, w których katalog projektu jest kopiowany do folderu Tagi i otrzymuje nazwę. Zajrzyj do dokumentacji, a zobaczysz, co mam na myśli. Wiem, że to wygląda dziwnie, ale przyzwyczajasz się do tego.

Ta strona może przynieść pewne korzyści (chociaż nie mogę za nią ręczyć): Konfigurowanie modularnego repozytorium svn dla stron php http://www.howtoforge.com/set-up-a-modular-svn-repository-for -php-strony internetowe

Z wielkim szacunkiem dla większości mądrości, która pojawia się powyżej - i jest to mądre - wdrażanie kontroli wersji jest jak wdrażanie systemów monitorowania. Moi klienci mówią „co powinienem monitorować”, a oczywistą odpowiedzią jest „monitoruj wszystko”. Ale to nie jest mile widziana wiadomość: mają 350 systemów, z których każdy ma 20-30 zmiennych systemowych oraz kilka zmiennych specyficznych dla użytkowania, i wszystkie można użytecznie monitorować; ale jest tylko jeden ze mnie i chcieliby zobaczyć wyniki w ciągu dwóch tygodni.

Chociaż zgadzam się, że najlepszą praktyką jest kontrolowanie wersji wszystkiego, jeśli to nie jest praktyczne w pierwszej kolejności, zacznij od kontrolowania tych rzeczy, których brak kontroli sprawiał ci najwięcej problemów do tej pory .

Jeśli większość awarii spowodowanych jest przez kod aplikacji, zacznij od kontrolowania tego; jeśli większość z nieplanowanych łat CSS, kontroluj to; i tak dalej.

Zapewni to nie tylko najlepszy zwrot z inwestycji czasu, ale z kolei uzasadni przedłużenie stosowania kontroli wersji w przyszłości: „Ponieważ dodaliśmy kontrolę wersji do kodu aplikacji, nieplanowane przestoje w ciągu 30 minut spadły z 11 na miesiąc do 2. Te dwa były spowodowane statycznymi zmianami HTML, więc zamierzamy kontrolować te później. ”.

Stopniowe wdrażanie zapewnia również wykwalifikowanych użytkowników wewnątrz organizacji. Tak, musiałeś nauczyć wszystkich sześciu programistów aplikacji, jak korzystać z systemu, ale nauczyli się i nie mają nic przeciwko; teraz, gdy nadszedł czas, aby wprowadzić system do zespołu CSS, masz sześciu dodatkowych ekspertów wewnętrznych niż trzy miesiące temu. Do tego czasu możesz nawet nawrócić; programista, któremu udało się uratować tyłek dzięki możliwości natychmiastowego wycofania szkodliwej zmiany, może być najlepszym ewangelistą w zespole CSS.

Edycja 1: jeśli zdecydujesz się pójść tą drogą, tani back-stop jako chipy polega na dodaniu tripwire na górze, przynajmniej na pudełku produkcyjnym. W ten sposób, jeśli Things Break, ale VCS stwierdzi, że nie jest obecnie odpowiedzialny za to, możesz szybko zidentyfikować, co się zmieniło, co zarówno przyspiesza poprawkę, jak i sugeruje twojego następnego kandydata do kontroli wersji.

Kontrola wersji wszystko. Nie ma sensu mieć plików HTML pod kontrolą wersji, a następnie całkowicie wkręcać witrynę z powodu zmiany w CSS, która nie jest kontrolowana i dlatego nie może być łatwo odwrócona.

Pułapki: osobiście nie natknąłem się na to podczas mojego dość ograniczonego korzystania z kontroli wersji.

Wdrożenie: Obecnie używam subversion hostowanej na urządzeniach Windows, zarówno w pracy, jak i w domu. Windows tylko dlatego, że to jest dostępne. W przeciwnym razie równie łatwo mógłby to być inny system operacyjny. Klucz dla użytkowników niezwiązanych z technologią, aby dać im proste narzędzie oparte na graficznym interfejsie użytkownika do obsługi importów, eksportów, zatwierdzeń, różnic itp. Które narzędzie będzie nieco zależeć od używanego systemu operacyjnego i systemu VCS.

Zastosowanie: Kiedy dokonuję zmian w kodzie, często testuję i zatwierdzam. To pozwala mi cofnąć się tak daleko, jak to konieczne, kiedy popsuję. Dodatkowo, porównując różne wersje i kopiując części kodu, nie muszę tracić każdej zmiany tylko dlatego, że muszę powrócić do poprzedniej wersji, aby naprawić pewne poprawki w innej części kodu.

Dodatkowa korzyść: Możesz dać dostęp do repozytorium źródłowego przez VPN lub bezpieczne połączenie, umożliwiając użytkownikom pracę z domu lub z innego miejsca. np. może wpadnę na pomysł w domu i tam edytuję kod pracy, zanim stracę tę myśl.

Wersja wszystko.

Wdrożenie zależy od tego, ile trzeba „dostosować” dla każdej z tych witryn. Jeśli są identyczne, z wyjątkiem jednego lub dwóch plików konfiguracyjnych, możesz po prostu sprawdzić kopię kodu i wprowadzić niewielkie zmiany. W razie potrzeby uruchom polecenie aktualizacji kontroli wersji dla każdego klienta.

Jeśli wybierzesz model dystrybucji „kasa bezpośrednio do witryny klienta”, upewnij się, że Twój serwer wyklucza dostęp do katalogów kontroli wersji, aby ludzie nie mogli przeglądać witryny http://example.com/. git / i zajrzyj do wnętrza. Ponadto zdecydowanie miałbym wirtualnego hosta testowego i produkcyjnego dla każdego klienta, aby upewnić się, że aktualizacja witryny nie będzie szaleć. Zwłaszcza jeśli wprowadzasz niestandardowe zmiany w plikach poszczególnych klientów, musisz poradzić sobie z konfliktami, zanim zmiany zostaną wprowadzone w życie. W takim przypadku sprawdzasz / aktualizujesz testowy host wirtualny, a gdy wszystko działa poprawnie, kopiujesz testowy host wirtualny na produkcyjny host wirtualny.

Wszystko, co ludzie mówią o tym, co do wersji, jest dobre.

Jeśli zdecydujesz się na subversion, mogę polecić wypróbowanie stosu Bitnami Trac; http://bitnami.org/stack/trac

Upraszcza konfigurowanie subversion dla Ciebie, jest wyposażony w system biletowy (którego możesz użyć na tym etapie lub nie) do śledzenia zmian i błędów oraz wiki, której możesz użyć, aby udokumentować, w jaki sposób chcesz używać programistów system.

Daj wszystkim programistom Windows TortoiseSVN. Naucz wszystkich kilku podstawowych zasad wiersza poleceń svn.

Pod koniec dnia narzędzie jest mniej ważne niż sposób myślenia, który trzeba zaszczepić w programistach. Mam nadzieję, że wkrótce zobaczą, że kontrola wersji jest Dobrą Rzeczą, ponieważ powstrzymuje ich przed utratą pracy i pozwala im powrócić z ślepych zaułków, które prowadzą ich nigdzie z powrotem do znanych dobrych stanów. Korzyści przeważają nad (niewielkim) kosztem ogólnym.