Zaczynam od SVN. Znam podstawowe polecenia i rozumiem podstawowe zasady. Zastanawiałem się, czy ktoś ma jakieś wskazówki lub najlepsze praktyki dotyczące pracy z Subversion w środowisku zespołowym.
Widzę korzyści z dodawania rozsądnie pełnych wiadomości podczas zatwierdzania kodu, ale czy są inne rzeczy, o których powinienem pamiętać?
Dzięki za wszystkie świetne odpowiedzi - bardzo pomogły.
Odpowiedzi:
Zachęcaj do częstych zatwierdzeń. Członkowie zespołu, którzy nie znają kontroli wersji, mogą czuć, że muszą trzymać kod poza repozytorium, dopóki „nie zadziała prawidłowo”. Naucz wszystkich angażować się wcześnie i często jak najszybciej znajdować problemy. Zamiast trzymać kod, dopóki to nie zadziała, zaproponuj swoim kolegom z zespołu tworzenie gałęzi dla funkcji, która może zepsuć trunk. To prowadzi do ...
Ustal praktykę rozgałęziania i tagowania. Oprócz gałęzi dla funkcji, zachęcaj swoich kolegów z drużyny do używania gałęzi do naprawiania dużych błędów. Oznaczaj główne poprawki błędów na początku i na końcu pracy. Utrzymuj tagi (i prawdopodobnie gałęzie) dla wersji produkcyjnych / QA.
Ustanów politykę dla linii głównej i trzymaj się jej. Jednym z przykładów może być: „trunk musi zawsze budować bez błędów”. lub „łącze trunk musi zawsze przejść wszystkie testy jednostkowe”. Wszelkie prace, które nie mogą jeszcze spełniać standardów magistrali, muszą być wykonywane w oddziale.
Nie zatwierdzaj zmian formatowania wraz ze zmianami kodu
Jeśli chcesz zmienić strukturę białych znaków ( Control+ K+ D) w gigantycznym pliku , w porządku. Zatwierdź zmianę formatowania oddzielnie od rzeczywistej zmiany logicznej. To samo dotyczy przenoszenia funkcji w plikach. Zatwierdź przeniesienie niezależnie od faktycznej edycji.
Jedną z kluczowych koncepcji, której zawsze się trzymam, jest wspólne wprowadzanie zmian w kodzie . Wynika z tego, że nie zatwierdzaj niepowiązanych zmian kodu w tym samym zatwierdzeniu . Oznacza to, że nie naprawiaj 2 błędów w jednym zatwierdzeniu (chyba że jest to ta sama poprawka) i nie wykonuj połowy poprawki błędu w każdym z 2 zatwierdzeń. Ponadto, jeśli muszę dodać jakieś nowe ulepszenie lub coś do niepowiązanej części systemu, której potrzebuję do innej pracy, zatwierdzam to ulepszenie osobno (i najpierw). Chodzi o to, że każda zmiana, którą ktokolwiek mógłby chcieć wprowadzić samodzielnie (lub cofnąć się samodzielnie), powinna być oddzielnym zatwierdzeniem. Pozwoli to zaoszczędzić mnóstwo bólu głowy, gdy nadejdzie czas na scalenie lub przywrócenie uszkodzonych funkcji.
Wiele już zostało wspomnianych, a oto kilka więcej:
Jeśli masz pliki, których nie chcesz mieć w kontroli źródła (np. Konfiguracja, skompilowane pliki itp.), Dodaj je do listy ignorowanych . W ten sposób zauważysz pliki, które zapomnisz dodać, zawsze oczekując pustej listy plików wyświetlanych jako nieznane w SVN.
Dodaj zdarzenie po zatwierdzeniu, które wyśle wiadomość e-mail na twoją listę mailingową deweloperów (lub taką, która jest specyficzna dla tego celu), dotyczącą zatwierdzonej zmiany i idealnie dla niej łatki.
Zintegruj ze swoim trackerem błędów , aby odniesienia do zatwierdzeń pojawiały się w błędach / żądaniach funkcji z linkami do różnic. Obsługują to narzędzia do śledzenia błędów, takie jak MantisBT .
Rozważ integrację z ciągłą integracją (np. CruiseControl.NET ), NAnt for Build i NUnit / VS dla testów jednostkowych. W ten sposób, gdy użytkownik zamelduje się w kodzie lub w zaplanowanym przedziale czasu, kod zostanie skompilowany, zostaną uruchomione testy jednostkowe, a programista otrzyma informację zwrotną o procesie. Zaalarmowałoby to również resztę zespołu, jeśli repozytorium jest uszkodzone (tj. Nie jest budowane).
Cóż, podstawy:
Odpowiedzi, których udzielają ludzie, są świetne. Wiele z tego jest podsumowanych w dokumentacji użytkownika svn zawierającej najlepsze praktyki dotyczące SVN .
Powtarzać:
Chciałbym podsumować najlepsze praktyki, których się trzymam:
Powinna istnieć struktura repozytorium . Osobiście korzystam z następującej struktury repozytorium:
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA(pre-alpha), A(alpha), B(beta), AR(alpha-release), BR(beta-release), RC(release release), ST(stabilny).Możesz znaleźć zarys moich najlepszych praktyk w Subversion w postaci diagramu ilustrującego główne zasady podejścia do zarządzania konfiguracją oprogramowania, które stosuję.
Jedną z rzeczy, które uznałem za bardzo przydatne, jest właściwość svn: external, która oznacza, że możesz odwoływać się do katalogów z innych repozytoriów do własnego. Daje naprawdę fajne sposoby organizowania kodu i danych. Oto kilka przykładów:
Skorzystaj z integracji z oprogramowaniem do śledzenia błędów. Jeśli używasz Bugzilli , możesz ją ustawić tak, aby jeśli Twój komentarz zaczynał się od „Bug XXXX”, Twój komentarz SVN jest automatycznie dodawany jako komentarz do podanego błędu, w tym łącze do interfejsu internetowego SVN do tej wersji.
Dowiedz się o narzędziach i konwencjach do rozgałęziania i scalania SVN.
Najlepszym sposobem pracy z innymi członkami zespołu jest rozbicie pracy na kompletne funkcje programistyczne / poprawki, a następnie praca nad indywidualnymi zmianami, każdą w gałęzi. Następnie scal zmiany z powrotem do głównej gałęzi / linii głównej, gdy zostaną ukończone / gotowe / zatwierdzone do scalenia.
W ten sposób jednostki mogą pracować nad wspólnym celem (na tej samej gałęzi lub na oddzielnych gałęziach) bez kolidowania z innymi zmianami.
Twój przebieg może się różnić, a to może być przesadą tylko dla dwóch lub więcej osób.
Jest to znacznie łatwiejsze, jeśli używasz dobrych narzędzi, które dobrze integrują się z SVN. Ułatwiają one sprawdzenie, co zostało zmienione, a następnie zatwierdzenie całości lub części zmian oraz częste aktualizowanie kopii roboczej do najnowszej wersji w SVN.
Polecam Tortoise SVN (jeśli używasz Windows) i Visual SVN (jeśli używasz VS).
Sprawdź również, czy możesz ustawić to tak, aby otrzymywać e-mail lub podobne powiadomienie za każdym razem, gdy zmiana zostanie zatwierdzona (zwykle zawiera również komunikat o zatwierdzeniu i listę zmienionych plików). Oferują to usługi takie jak CVSDude . Uważam, że pomocne jest wiedzieć zarówno, że aktualizacja została dokonana, a następnie mieć pewne pojęcie o tym, co zawiera ta aktualizacja, zanim zaktualizuję kopię roboczą.
Oprócz polityk rozgałęziających i in. (gdzie jeden rozmiar zdecydowanie nie pasuje do wszystkich), powinieneś mieć dobre commity:
Złota zasada kontroli źródła: zamelduj się wcześnie, zamelduj się często
Aby uzyskać wskazówki, jak zorganizować repozytorium:
Skonsultuj się ze swoim zespołem na temat ich zmian lub przynajmniej przyjrzyj się bardzo uważnie różnicom, zanim naprawisz jakiekolwiek konflikty scalania. Poproś ich, aby sami przejrzeli scalony kod, aby upewnić się, że ich dodatki nie zostały utracone podczas scalania.
Jedną z rzeczy, które widziałem, która zmniejsza zepsute zatwierdzenia, jest posiadanie dobrych skryptów przed zatwierdzeniem. Na przykład można uruchomić dowolne testy jednostkowe przed zatwierdzeniem zmiany. Spowoduje to, że zatwierdzanie będzie trochę powolne, ale oszczędzasz czas, unikając nadepnięcia komuś na palce i konieczności przepraszania. Oczywiście staje się to o wiele trudniejsze do zarządzania, gdy masz duży zespół programistów i bardzo często zatwierdzasz.
Jednym z przykładów integracji z trackerem błędów i egzekwowaniem polityki zatwierdzania mogą być skrypty przechwytujące svn Traca przed / po zatwierdzeniu, które mogą odmówić zatwierdzenia, jeśli wiadomość o zatwierdzeniu nie odnosi się do żadnego biletu w module śledzenia błędów i dodaje komentarze do istniejących bilety oparte na zawartości wiadomości (tj. komunikat o zatwierdzeniu może zawierać coś w rodzaju „Poprawki # 1, # 2 i # 8”, gdzie # 1, # 2, # 8 to numery zgłoszeń).
Najlepsza praktyka korzystania z SVN :
Kiedy po raz pierwszy przyszedłeś do biura i otworzyłeś swój projekt Eclipse , pierwszym krokiem, który musisz zrobić, jest aktualizacja projektu.
Po zaktualizowaniu rozpocznij pracę. Po zakończeniu kodowania sprawdź, czy Twoja aplikacja działa poprawnie bez żadnych wyjątków. Gdy masz pewność, że kod działa prawidłowo, czas go zatwierdzić.
Uwaga: podczas zatwierdzania kodu nie zatwierdzaj bezpośrednio. Zsynchronizuj się z serwerem i sprawdź, co należy zrobić. Uwaga: nie zatwierdzaj całego folderu raz. Ponieważ możliwe, że dokonałeś pewnych zmian w pliku zgodnie z wymaganiami lub możesz usunąć niektóre pliki w systemie lokalnym. Ale ustawienia są inne na serwerze. Więc sprawdź pliki indywidualnie i zatwierdź kod.
Nie zatwierdzaj / aktualizuj plików konfliktów bezpośrednio.
Kiedy nadpisywać i aktualizować?
Kiedy jesteś prawie pewien, że nie potrzebujesz żadnych lokalnych zmian i chcesz całkowicie zaktualizować kopię serwera. Zwróć uwagę, że jeśli raz dokonasz nadpisania i aktualizacji, nie otrzymasz żadnych lokalnych zmian.
Uwaga: nie przechowuj projektu bez aktualizacji dłużej niż jeden dzień. Nie przechowuj kodu bez zatwierdzania przez wiele dni.
Poinformuj, kto pracuje nad tym samym komponentem i omów, jakie zmiany wprowadzili każdego dnia.
Nie zatwierdzaj właściwości i pliku konfiguracyjnego, chyba że jest jakiś powód. Ponieważ ustawienia będą inne na serwerze iw chmurze.
Nie zatwierdzaj folderów docelowych do SVN, tylko kod źródłowy i foldery zasobów muszą być utrzymywane w repozytorium SVN.
Kiedy zgubiłeś kod, nie panikuj! Możesz odzyskać wcześniejszą kopię z historii SVN.
Nie wysyłaj projektu do wielu miejsc na dysku. Sprawdź to w jednym miejscu i pracuj z nim.
SVN sam w sobie to dobry początek, a niektóre inne postery przedstawiają świetne sugestie dotyczące najlepszych praktyk.
Jedyne, co chciałbym dodać, to to, że powinieneś łączyć SVN z CruiseControl lub TeamCity, aby prowadzić proces ciągłej integracji. Spowoduje to wysłanie wiadomości e-mail dotyczących kompilacji i powiadomienie wszystkich, gdy ktoś zepsuł kompilację.
To będzie bardzo wymowne, kto śledzi Twój proces, a kto nie. Może to prowadzić do pewnych tarć, ale na dłuższą metę twojej drużynie będzie lepiej.
Precyzyjny komentarz do każdego zatwierdzenia
Nie przerywaj (głównej) kompilacji!
Zatwierdź, gdy tylko jednostka logiczna ulegnie zmianie
Unikaj używania Subversion jako narzędzia do tworzenia kopii zapasowych
Trochę rozgałęziania / scalania, jak to możliwe
.
Więcej szczegółów można znaleźć w sprawdzonych metodach SVN .
Pamiętaj, że im bardziej przyrostowe, modułowe, dyskretne i zwięzłe zobowiązania będą, tym łatwiej będzie Tobie (lub prawdopodobnie innym):
Użyj tego dla szablonu komentarzy:
[zadanie / historia xxx] [drugorzędne / główne] [komentarz] [komentarz uzupełniający] [adres URL do błędu]