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?