Najlepsze praktyki SVN - praca w zespole

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.

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:

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

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

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

4. 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:

• Utwórz tagi przed rozpoczęciem kontroli jakości wersji
• Twórz tagi przed ryzykownymi zmianami (np. Dużymi refaktorami)
• Utwórz gałęzie dla wydanych wersji, aby zamrozić kod.
• Upewnij się, że ludzie wiedzą o konieczności aktualizacji przed rozpoczęciem pracy nad fragmentem kodu i dokonaj aktualizacji jeszcze raz przed jej wykonaniem.
• SVN umożliwia wielokrotne wyewidencjonowywanie tego samego pliku przez różnych użytkowników. Upewnij się, że wszyscy rozwiązują wszelkie konflikty, które mogą wystąpić.
• Nigdy nie używaj tego samego konta SVN dla więcej niż jednego użytkownika. Skutkiem mogą być straszne rzeczy.

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ć:

1. Skonfiguruj strukturę repozytorium (powinieneś mieć katalog główny projektu z linią główną, gałęziami i tagami pod spodem)
2. Wybierz rozgałęzianie zasad (gałęzie prywatne, gałęzie na kamień milowy / wydanie / błąd itp.) I trzymaj się tego - zalecałbym więcej rozgałęzień zamiast mniej, ale nie ma potrzeby tworzenia oddziałów prywatnych
3. Wybierz zasady ponownego tagowania - im więcej tagów, tym lepiej, ale przede wszystkim określ konwencje nazewnictwa tagów
4. Wybierz politykę ponownie zobowiązującą się do połączenia trunkingowego - utrzymuj łącze trunk tak „czyste”, jak to tylko możliwe, powinno być możliwe do wydania w dowolnym momencie

Chciałbym podsumować najlepsze praktyki, których się trzymam:

1. Nie zatwierdzaj plików binarnych . Powinno istnieć oddzielne repozytorium dla plików binarnych, takich jak Nexus , Ivy czy Artifactory .

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

3. Użyj określonej listy typów oddziałów . Moja lista jest następująca: eksperymentalna , konserwacja , wersje , platformy , wydania .
4. Używaj określonych typów tagów : PA(pre-alpha), A(alpha), B(beta), AR(alpha-release), BR(beta-release), RC(release release), ST(stabilny).
5. Zminimalizuj konieczność łączenia . Powinny istnieć zasady, kiedy łączenie jest możliwe / zalecane, a kiedy nie.
6. Numeracja wersji . Powinien zostać ustalony sposób numerowania wersji, którego należy się trzymać. Zwykle jest to opisane w takim dokumencie jak Plan Zarządzania Konfiguracją Oprogramowania, jest częścią dokumentacji projektowej wysokiego poziomu. Osobiście stosuję złożone podejście do numeracji wersji. Zgodnie z tym podejściem wersje mają następujące wzorce: Nxx (gałęzie utrzymania / wsparcia), NMx (gałąź wydania), NxK (kompilacja), NMK (wydanie).
7. Wykonuj tak często, jak to możliwe . Jeśli wydaje się to trudne (na przykład, gdy powinno być zbyt wiele zmian do wprowadzenia funkcji, a nawet kompilacji kodu), należy zastosować gałęzie eksperymentalne.
8. Pień powinien zawierać najnowsze osiągnięcia . Na przykład, gdy istnieje wybór, gdzie opracować nową główną wersję ( Nxx ) aplikacji, w magistrali lub w gałęzi, zawsze należy podejmować decyzję na korzyść magistrali . Stara wersja powinna być odgałęziona na gałąź Maintenance / Support . Zakłada, że ​​istnieje wyraźne rozróżnienie między wersjami głównymi, a ich specyfika (architektura, kompatybilność) pojawia się możliwie najwcześniej .
9. Ścisłe zasady „nie przerywaj kompilacji” w gałęziach wydania . W międzyczasie niekoniecznie musi być rygorystyczny dla linii głównej, o ile może mieć eksperymentalny rozwój lub bazę kodów, która wymaga rozwiązania problemów ze scalaniem.
10. Użyj svn: externals . Pozwoli to na modularyzację projektu, ustanowienie przejrzystej procedury zarządzania wydaniami, podzielenie i podbicie różnych funkcjonalności.
11. Użyj śledzenia problemów . Będziesz mógł wskazać odniesienie do problemu w komunikacie zatwierdzenia.
12. Wyłącz puste komunikaty o zatwierdzeniach . Można to zrobić za pomocą haków przed zatwierdzeniem.
13. Zdefiniuj, które gałęzie chcesz stale integrować . Na przykład wolę ciągłą integrację dla gałęzi trunk , maintenance i release .
14. Ustanowienie polityki ciągłej integracji dla różnych typów oddziałów. Jak wspomniałem wcześniej, najbardziej rygorystyczne zasady „nie psuj kompilacji” dotyczą wydawania gałęzi, podczas gdy gałęzie trunk i Maintenance mogą czasem ulec uszkodzeniu. Istnieje również różnica między listą inspekcji przeprowadzanych na gałęzi głównej / konserwacyjnej i gałęzi wydania .

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:

1. Jeśli masz oddzielne repozytoria dla kodu różnych modułów / bibliotek i odniesień w tych, których używasz. Oznacza to, że możesz mieć meta repozytorium dla każdego pliku wykonywalnego. Jeśli jest to mały plik wykonywalny, który używa tylko kilku modułów, nie musisz pobierać całego drzewa. W efekcie otrzymujesz numery wersji SVN na moduł.
2. Dodawanie dużych danych binarnych, takich jak skompilowane wersje bibliotek, do repozytorium kodu jest ogólnie uważane za zły nawyk, ale może być naprawdę wygodne. Jeśli po prostu dodasz wszystkie wersje wszystkich używanych bibliotek do innego repozytorium, możesz uzyskać to, co najlepsze z dwóch światów. Odwołujesz się do wersji bibliotek, których używasz w repozytorium kodu. Podczas sprawdzania repozytorium kodu otrzymasz zarówno kod, jak i pliki binarne. Jednak pliki binarne są przechowywane w dużym repozytorium, którego nie trzeba tworzyć tak rygorystycznie, jak kod źródłowy, a repozytorium kodu źródłowego pozostaje małe i zawiera tylko tekst.

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:

• Jeśli to możliwe, zatwierdzenie powinno odnosić się do pojedynczego fragmentu pracy; poprawka błędu, nowa funkcja - powinna istnieć „logika” co do wprowadzanych zmian
• Zatwierdzenie powinno mieć opisowy komentarz, który pomoże ci zlokalizować go podczas przeglądania historii repozytorium. Większość ludzi sugeruje napisanie na początku jednego zdania opisującego cały commit i bardziej szczegółową relację poniżej
• Jeśli to możliwe, powinieneś powiązać zatwierdzenie ze swoim systemem śledzenia błędów, jeśli to możliwe. Trac, Redmine i in. pozwalają tworzyć linki od błędów do zatwierdzeń i odwrotnie, co jest bardzo przydatne.

Złota zasada kontroli źródła: zamelduj się wcześnie, zamelduj się często

Aby uzyskać wskazówki, jak zorganizować repozytorium:

• Jak organizujesz repozytorium kontroli wersji?
• Książka SVN Rozdział 5. Administracja repozytorium
• Układ 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 :

1. Kiedy po raz pierwszy przyszedłeś do biura i otworzyłeś swój projekt Eclipse , pierwszym krokiem, który musisz zrobić, jest aktualizacja projektu.

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

3. Nie zatwierdzaj / aktualizuj plików konfliktów bezpośrednio.

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

5. Poinformuj, kto pracuje nad tym samym komponentem i omów, jakie zmiany wprowadzili każdego dnia.

6. Nie zatwierdzaj właściwości i pliku konfiguracyjnego, chyba że jest jakiś powód. Ponieważ ustawienia będą inne na serwerze iw chmurze.

7. Nie zatwierdzaj folderów docelowych do SVN, tylko kod źródłowy i foldery zasobów muszą być utrzymywane w repozytorium SVN.

8. Kiedy zgubiłeś kod, nie panikuj! Możesz odzyskać wcześniejszą kopię z historii SVN.

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

Wykonuj pracę DEV na oddziałach

1. Częste zobowiązania do Twojego oddziału
2. Dyskretne / modułowe zobowiązania do Twojego oddziału ( patrz tutaj )
3. Często aktualizuj / łącz z magistrali. Nie siedź na swojej gałęzi bez ponownego bazowania

Community Trunk

1. Powinien zawsze budować / działać
2. Jeden problem na zatwierdzenie ( ponownie zobacz tutaj ) Przeważnie po to, abyś ty lub inni mogli wycofywać się pojedynczo
3. Nie łącz zmian refaktoryzacji / białych znaków ze zmianami logicznymi. Twoi koledzy z drużyny będą mieli trudności z wydobyciem tego, co faktycznie zrobiłeś z zatwierdzenia

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

• Stopniowo wycofuj zmiany
• Wizualnie uświadom sobie, co faktycznie zrobiłeś, bez przesiewania ton białych znaków i zmiany nazw zmiennych.
• Komunikaty dotyczące zatwierdzenia mają większe znaczenie, gdy stosunek wykonanej pracy do długości wiadomości jest niższy.

Użyj tego dla szablonu komentarzy:

[zadanie / historia xxx] [drugorzędne / główne] [komentarz] [komentarz uzupełniający] [adres URL do błędu]