Opracowanie strategii kontroli wersji dla SVN

Niezwłocznie spróbuję wymyślić strategię kontroli wersji dla mojej firmy; obecnie używamy SVN, ale nie ma w tym żadnej struktury - w zasadzie mamy tylko łącze i tylko się do tego zobowiązujemy. Ostatnio kierownik ds. Rozwoju uruchomił drugie repozytorium, które działa jak nasz „tag”, ale musi zostać ręcznie scalone z „trunk”, ponieważ nie jest ono częścią tego samego repozytorium, ale jest całkowicie oddzielne. W efekcie istnieje tylko jeden folder, zwany „Dev” (w rzeczywistości istnieją różne foldery „Dev” w różnych datach, ale tylko „Dev” jest głównym), a pod nim jest wszystko inne; wszystkie inne projekty. W ogóle nie jest zorganizowany według projektu, nie ma pojęcia gałęzi / tagu / pnia ani niczego. Osoba, która początkowo go skonfigurowała (dawno minęła, oczywiście) wydawało się, że w ogóle nie wie, jak ustawić SVN, i od tego czasu nikt nie zadał sobie trudu, aby nauczyć się, jak robić to właściwie, w obawie przed pęknięciem. Nie używamy żadnego CI (ani testów automatycznych, niestety).

Po pierwsze, czy powinniśmy to rozdzielić według projektu? Na przykład mamy: dwie witryny sieci Web ASP.NET (nie aplikacje WWW, witryny sieci Web), usługę sieci Web, folder wdrażania dla wszystkich skryptów tabel i procedur przechowywanych, dwóch klientów wiersza polecenia dla projektów zewnętrznych, które są wywoływane przez Strony internetowe i folder współdzielony, który ma wspólne obiekty biznesowe i tym podobne. Czy każdy z nich powinien być własnym projektem z konfiguracją gałęzi / tagów / pni, czy powinien wyglądać tak:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

i masz wszystkie gałęzie i wszystko ma kopię całego folderu Dev? Takie podejście może być łatwiejsze do przełknięcia, ponieważ często zdarzają się sytuacje, w których musimy wprowadzić zmiany we współużytkowanej bibliotece kodów i co najmniej jednej (zwykle obu) witrynach.

Po drugie, robimy regularne wydania („wypycha” nasz język) na nasz serwer deweloperów i serwer na żywo. Z tego, co przeczytałem, najlepszym sposobem, aby sobie z tym poradzić, byłoby to, że cały rozwój przechodzi do pnia /, gałęzie są „tymczasowe” i służą do dodawania nowej funkcji, która może wpływać na pień, a tagi są dla wydań? Tak więc pchamy co miesiąc, powiedzmy, i pracuję nad nowym modułem. Rozgałęziałem pień i użyję tej gałęzi do mojego kodu, pisząc i testując go i cokolwiek innego. Kiedy moduł jest gotowy, scalę go z powrotem w bagażnik (i może usunę gałąź), a kiedy będziemy gotowi do wdrożenia, oznaczymy go tagiem (powiedzmy „May2011”). Jeśli mamy naprawioną usterkę po jej uruchomieniu, zostanie ona naprawiona w tagu May2011 i scalona w pień (więc paczka również otrzyma poprawkę), a następnie maj 2011 zostałby ponownie wypchnięty z poprawką? Czy to jest intencja tagowania?

Jeśli chcesz zunifikowanego procesu kompilacji, umieść gałęzie / tagi / pień w katalogu głównym, w następujący sposób:

branches/
tags/
trunk/
  dev/
    ...

Jeśli nie potrzebujesz zunifikowanego procesu kompilacji, możesz umieścić gałęzie / znaczniki / pnie w każdym projekcie, jeśli chcesz. Jednak migracja do ujednoliconej wersji może być trudna po umieszczeniu ich w każdym projekcie. Ujednolicona kompilacja ma zalety, takie jak eliminacja potrzeby publikowania współdzielonych komponentów między projektami - wszystkie one są częścią kompilacji.

Osobiście lubię ujednolicony proces kompilacji. Co więcej, nie sądzę, że powinieneś mieć projekt „dev”. Powinieneś mieć projekty bezpośrednio pod pniem, a następnie rozgałęzić pień do gałęzi programisty. Użyj tagów w wydaniach. Na przykład zrobiłbym to tak:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1. Jeśli chodzi o strukturę kodu w svn, jest to naprawdę osobisty wybór.

Sugerowałbym, że jeśli projekty są powiązane lub współużytkują kod, to chcą wspólnego pnia. Jeśli są niezależni, to chcą osobnych łączy lub nawet osobnych repozytoriów. Jeśli kiedykolwiek będziesz potrzebować dostarczyć stronie trzeciej kopię historii svn dla projektu, o wiele łatwiej jest, jeśli jest ona w osobnym repozytorium.

W twoim przypadku brzmi to tak, jakby szkic, który naszkicowałeś powyżej byłby rozsądny, ponieważ masz wspólny kod i chciałbyś, aby gałęzie / znaczniki zawierały ten wspólny kod.

1. Twój opis użycia tagu i gałęzi brzmi niezwykle sensownie i tak właśnie oczekiwałbym użycia svn. Taki jest właśnie zamiar tagowania w moim rozumieniu. BTW w tagach i gałęziach svn są w rzeczywistości tym samym, ale terminologia jest stosowana tak, jak ją zastosowałeś.

Osobiście dodałbym również zastrzeżenie, że wszystko, co jest związane z bagażnikiem, musi zbudować, musi być atomowe i nie powinno przełamywać żadnych testów jednostkowych. Oddziały przeznaczone są do niedokończonej pracy w toku. Oczekiwałbym, że bagażnik będzie potencjalnym kandydatem do wydania w dowolnym momencie.

Poniżej przedstawiono najlepszy sposób utworzenia repozytorium Subversion

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

W ten sposób możesz samodzielnie sprawdzić poszczególne projekty.

Jeśli chcesz sprawdzić wszystkie 3 projekty i wykonać ujednoliconą kompilację z jakimś monolitycznym skryptem / systemem kompilacji, to zbadaj za pomocą modułu głównego z svn: zewnętrznymi mapującymi wszystkie inne projekty na master trunk .

Na pierwszy rzut oka jest to bardziej skomplikowane, ale jest to najbardziej konserwowalny i idiomatyczny sposób rozwiązania tego problemu za pomocą Subversion.