Migracja SVN do Git — przygotowanie do migracji

Skrypty migracji firmy Atlassian

Jeśli chcesz dokonać błyskawicznego przejścia na Git, skrypty migracji firmy Atlassian będą dobrym rozwiązaniem. Uwzględniają one wszystkie narzędzia potrzebne do niezawodnej konwersji istniejących repozytoriów SVN na repozytoria Git. Uzyskana w efekcie ich użycia natywna dla Git historia pozwoli uniknąć problemów ze współdziałaniem SVN i Git po przeprowadzeniu konwersji.

Udostępniliśmy kompletny przewodnik techniczny dotyczący korzystania z tych skryptów do konwersji całej bazy kodu na kolekcję repozytoriów Git. Objaśniono w nim wszystkie zagadnienia — od wyodrębniania danych autora z SVN po reorganizację niestandardowych struktur repozytoriów SVN.

Wtyczka SVN Mirror for Stash (teraz Bitbucket)

SVN Mirror for StashSVN Mirror for Stash jest wtyczką Bitbucket, która w prosty sposób umożliwia prowadzenie hybrydowej bazy kodu współpracującej zarówno ze środowiskiem SVN, jak i Git. W odróżnieniu od skryptów migracji firmy Atlassian wtyczka SVN Mirror for Stash umożliwia równoczesne korzystanie z Git i SVN w tym samym projekcie przez dowolny czas.

To kompromisowe rozwiązanie to świetna opcja dla większych firm. Umożliwia stopniowe wdrażanie Git, pozwalając różnym zespołom na migrację przepływów pracy w dogodnym dla nich czasie.

Czym jest Git-SVN?

Narzędzie git-svn jest interfejsem między lokalnym repozytorium Git a zdalnym repozytorium SVN. Umożliwia programistom pisanie kodu i tworzenie commitów lokalnie w Git, a następnie wypychanie ich do centralnego repozytorium SVN w sposób właściwy dla commitów SVN. Takie rozwiązanie powinno mieć charakter tymczasowy, jednak przydaje się przy rozważaniu przejścia z SVN na Git.

Narzędzie git-svn jest dobrą opcją, gdy organizacja nie jest jeszcze zdecydowana na przejście na Git i chce dać programistom możliwość zapoznania się z Git bez przeprowadzania pełnej migracji. Idealnie nadaje się również do użycia podczas fazy szkoleniowej. Zamiast nagłego przejścia Twój zespół może najpierw zapoznać się z lokalnymi poleceniami Git, zanim zacznie się martwić o przepływy pracy bazujące na współpracy.

Należy pamiętać, że stosowanie narzędzia git-svn powinno być jedynie tymczasową fazą procesu migracji. W kwestii backendu bazuje ono wciąż na systemie SVN, dlatego nie daje możliwości skorzystania z bardziej złożonych funkcji Git, takich jak tworzenie gałęzi czy zaawansowane przepływy pracy oparte na współpracy.

Strategie wprowadzenia

Migracja bazy kodu jest tylko jednym z aspektów wdrażania Git. Trzeba również zastanowić się na sposobem wprowadzenia Git wśród osób stojących za tą bazą kodu. Trzy główne strategie migracji zespołu programistycznego do Git zakładają wykorzystanie konsultantów zewnętrznych, wewnętrznych specjalistów ds. Git oraz zespołów pilotażowych.

Zewnętrzni konsultanci Git

Konsultanci zajmujący się Git są w stanie w zasadniczej części przeprowadzić za Ciebie proces migracji za symboliczną opłatą. Zaletą takiego rozwiązania jest utworzenie przepływu pracy Git doskonale dopasowanego do potrzeb Twojego zespołu bez konieczności poświęcania czasu na jego samodzielne opracowywanie. Ponadto w trakcie nauki Git Twój zespół zyskuje dostęp do zasobów szkoleniowych eksperta. Partnerzy Atlassian są specjalistami w dziedzinie migracji z SVN do Git i warto od nich zacząć, szukając konsultanta Git.

Z drugiej strony samodzielne zaprojektowanie i wdrożenie przepływu pracy opartego na Git będzie dla Twojego zespołu świetnym sposobem zrozumienia meandrów własnego procesu programistycznego. Pozwoli to uniknąć pozostawienia zespołu samego sobie po zakończeniu pracy przez konsultanta.

Wewnętrzni specjaliści ds. Git

Specjalistą ds. Git będzie programista w Twojej firmie entuzjastycznie nastawiony do używania Git. Skorzystanie z pomocy takiej osoby jest dobrym rozwiązaniem dla firm, w której kultura programistyczna jest mocno rozwinięta, a programiści czują się komfortowo, stosując nowe rozwiązania. Zamysł polega na zapewnieniu jednemu z inżynierów możliwości uzyskania statusu eksperta w dziedzinie Git, aby mógł on zaprojektować oparty na Git przepływ pracy dostosowany do potrzeb firmy oraz pełnić funkcję wewnętrznego konsultanta, gdy nadejdzie czas przejścia reszty zespołu na Git.

Zaletą takiego rozwiązania w porównaniu z zaangażowaniem konsultanta zewnętrznego jest zatrzymanie specjalistycznej wiedzy dotyczącej Git w firmie. Wymaga ono jednak poświęcenia większej ilości czasu na wyszkolenie specjalisty ds. Git, a także stwarza ryzyko wybrania nieprawidłowego przepływu pracy Git lub jego niewłaściwego wdrożenia.

Zespoły pilotażowe

Trzecią opcją przejścia na Git jest przetestowanie go w zespole pilotażowym. Rozwiązanie to sprawdzi się najlepiej, gdy masz niewielki zespół, który pracuje nad względnie odizolowanym projektem. Ta opcja zadziała jeszcze lepiej, jeśli w zespole pilotażowym połączy się zewnętrznych konsultantów z wewnętrznymi specjalistami ds. Git.

Zaletą jest w tym przypadku konieczność uzyskania aprobaty całego zespołu, a także ograniczenie ryzyka wyboru niewłaściwego przepływu pracy, ponieważ przy projektowaniu nowego procesu programistycznego uwzględnia się opinie całego zespołu. Innymi słowy, brakujące elementy wychwytuje się szybciej niż w przypadku samodzielnego projektowania nowego przepływu pracy przez konsultanta lub specjalistę.

Z drugiej strony skorzystanie z zespołu pilotażowego oznacza więcej szkolenia na początku oraz dłuższy czas konfiguracji: zamiast jednego programisty pracującego nad nowym przepływem pracy mamy do czynienia z potencjalnym tymczasowym obniżeniem produktywności całego zespołu związanym z zapoznawaniem się z nowym przepływem pracy. Jednak długofalowe korzyści zdecydowanie przewyższają te krótkotrwałe trudności.

Bezpieczeństwo i uprawnienia

Kontrola dostępu jest tym aspektem Git, który wymaga fundamentalnego przemyślenia sposobu zarządzania bazą kodu.

W SVN cała baza kodu jest zazwyczaj przechowywana w jednym centralnym repozytorium, natomiast dostęp dla różnych zespołów i osób ogranicza się na poziomie poszczególnych folderów. W Git nie ma takiej możliwości: programiści muszą pobrać całe repozytorium, aby na nim pracować. Zazwyczaj nie można pobrać podzbioru repozytorium, jak w środowisku SVN. Uprawnienia można przyznawać tylko do całych repozytoriów Git.

Oznacza to, że musisz podzielić swoje duże, monolityczne repozytorium SVN na kilka małych repozytoriów Git. W Atlassian doświadczyliśmy tego na własnej skórze, gdy nasz zespół programistyczny pracujący nad systemem Jira przeprowadził migrację do Git. Wszystkie nasze wtyczki Jira były przechowywane w jednym repozytorium SVN, ale po migracji każda trafiła do własnego repozytorium.

Należy pamiętać, że Git został zaprojektowany z myślą o bezpiecznej integracji fragmentów kodu tworzonych przez tysiące niezależnych programistów systemu Linux, dlatego zdecydowanie oferuje jakąś możliwość skonfigurowania dowolnego rodzaju kontroli dostępu, której potrzebuje Twój zespół. Może to jednak wymagać świeżego spojrzenia na cykl kompilowania.

Jeśli obawiasz się o utrzymanie zależności między nową kolekcją repozytoriów Git, przydatne może okazać się zastosowanie dodatkowej warstwy zarządzania zależnościami ponad systemem Git. Warstwa zarządzania zależnościami pomoże skrócić czasy kompilowania, ponieważ w miarę rozrastania się projektu do przyspieszenia kompilowania konieczne będzie „buforowanie”. Wykaz zalecanych narzędzi do tworzenia warstwy zarządzania zależnościami dla każdego zestawu rozwiązań technologicznych można znaleźć w przydatnym artykule: „Git i zależności projektu”.

Repozytorium dla każdego programisty

Największą zmianą, do której musi przyzwyczaić się programista, jest rozproszony charakter środowiska Git. Zamiast jednego centralnego repozytorium, każdy programista ma własną kopię całego repozytorium. To radykalnie zmienia sposób współpracy z innymi programistami.

Zamiast wyewidencjonowywania repozytorium SVN za pomocą polecenia svn checkout i pobrania kopii roboczej, klonuje się całe repozytorium Git na własny komputer lokalny za pomocą polecenia git clone.

Współpraca odbywa się poprzez przenoszenie gałęzi między repozytoriami za pomocą poleceń git push, git fetch lub git pull. Udostępnianie odbywa się zwykle na poziomie gałęzi w Git, jednak może mieć miejsce także na poziomie commita, jak w SVN. Jednak w Git commit odzwierciedla całościowy stan całego projektu, a nie modyfikacje poszczególnych plików. Z uwagi na możliwość korzystania z gałęzi zarówno w Git, jak i w SVN, tym, co wyróżnia system Git, jest możliwość zatwierdzania lokalnego, bez udostępniania pracy. Zapewnia to większą swobodę eksperymentowania, pozwala skuteczniej pracować w trybie offline i przyspiesza niemal wszystkie polecenia związane z kontrolą wersji.

Trzeba jednak pamiętać, że zdalne repozytorium nie jest bezpośrednim łączem do repozytorium innego użytkownika. To po prostu zakładka, która eliminuje konieczność ponownego wprowadzania całego adresu URL za każdym razem, gdy wchodzisz w interakcję ze zdalnym repozytorium. Dopóki nie ściągniesz gałęzi ze zdalnego repozytorium lub jej do niego nie wypchniesz, pracujesz w odizolowanym środowisku.

Inną dużą zmianą dla użytkowników SVN jest podział na repozytoria „lokalne” i „zdalne”. Repozytoria lokalne znajdują się na komputerze lokalnym, natomiast wszystkie inne repozytoria nazywane są repozytoriami zdalnymi. Zdalne repozytorium służy głównie do udostępniania kodu pozostałym członkom zespołu, dlatego w tych repozytoriach nie prowadzi się aktywnie prac programistycznych. Repozytoria lokalne znajdują się na komputerze lokalnym i właśnie w nich prowadzone są wszystkie prace programistyczne.

Nie obawiaj się tworzenia gałęzi ani scalania

W SVN zatwierdzasz kod, edytując pliki w kopii roboczej, a następnie wykonując polecenie svn commit, aby wysłać kod do centralnego repozytorium. Wszyscy inni mogą następnie pobrać te zmiany do własnych kopii roboczych za pomocą polecenia svn update. Gałęzie SVN są zazwyczaj zarezerwowane dla dużych, długofalowych fragmentów projektu, ponieważ scalanie bywa niebezpieczne i może doprowadzić do uszkodzenia projektu.

W Git podstawowy przepływ prac programistycznych jest zupełnie inny. Zamiast powiązania z jedną linią prac programistycznych (np. trunk/) wszystko kręci się wokół tworzenia i scalania gałęzi.

Aby rozpocząć pracę nad czymkolwiek w Git, musisz utworzyć i wyewidencjonować nową gałąź za pomocą polecenia git checkout -b . W ten sposób tworzysz specjalną linię prac programistycznych, w której możesz pisać kod bez obawy, że będzie to miało wpływ na kogokolwiek innego w Twoim zespole. Jeśli zepsujesz coś do tego stopnia, że naprawa będzie niemożliwa, wystarczy, że odrzucisz gałąź za pomocą polecenia git branch -d . Gdy z kolei opracujesz coś przydatnego, tworzysz pull request z prośbą o scalenie tego z gałęzią main.

Potencjalne przepływy pracy Git

Przy wyborze przepływu pracy Git ważne jest, aby wziąć pod uwagę potrzeby swojego zespołu. Prosty przepływ pracy może zmaksymalizować tempo i elastyczność prac programistycznych, a bardziej złożony przepływ pracy może zapewnić większą spójność i kontrolę nad pracami w toku. Możesz wdrożyć i połączyć wymienione poniżej ogólne podejścia, dostosowując je do różnych potrzeb i ról w zespole. Główny programista może korzystać z gałęzi funkcji, podczas gdy wykonawca będzie na przykład pracował na podziale.

• Scentralizowany przepływ pracy jest najbardziej zbliżony do powszechnie stosowanych procesów SVN, dlatego stanowi on dobrą opcję na początek.
• Kontynuując tę myśl, korzystanie z przepływu pracy gałęzi funkcji pozwala programistom odizolować prace w toku i chronić ważne gałęzie współdzielone. Gałęzie funkcji dają również podstawę do zarządzania zmianami przy użyciu pull requestów.
• Przepływ pracy Gitflow jest bardziej formalnym, ustrukturyzowanym rozszerzeniem podejścia opartego na gałęziach funkcji, co czyni go świetną opcją dla większych zespołów mających dobrze zdefiniowane cykle wydawania.
• Warto również rozważyć przepływ pracy z podziałem, jeśli potrzebujesz maksymalnej izolacji i kontroli nad zmianami, gdy na jednym repozytorium pracuje wielu programistów.

Jeśli jednak, jako zespół profesjonalistów, chcecie w pełni wykorzystać potencjał Git, warto rozważyć przepływ pracy oparty na gałęziach funkcji. Jest to autentycznie rozproszony przepływ pracy, który zapewnia wysoki poziom bezpieczeństwa, duże możliwości skalowania i stanowi kwintesencję podejścia Agile.

Przeniesienie zespołu do Git może, ale wcale nie musi być trudne. W tym artykule omówiono kilka często spotykanych opcji migracji istniejącej bazy kodu, wprowadzania Git w zespołach programistycznych oraz radzenia sobie z kwestią bezpieczeństwa i uprawnień. Przedstawiliśmy również największe wyzwania, na które programiści powinni się przygotować w trakcie migracji.

Mamy nadzieję, że masz teraz solidne podstawy do wdrożenia rozproszonego procesu programistycznego w swojej firmie, niezależnie od jej rozmiaru i stosowanych dotychczas praktyk.