Wybieranie strategii przepływu kodu
Ważne jest, aby wybrać strategię przepływu kodu, która pasuje do sposobu działania zespołu. Masz kilka strategii, które należy wziąć pod uwagę. Na końcu modułu możesz eksplorować opcje. Zespół internetowy Tailspin decyduje się o opracowaniu strategii przepływu kodu opartej na usłudze Git i usłudze GitHub.
Po skonfigurowaniu usługi Azure Boards Mara wraz z zespołem określiła kilka wstępnych zadań do wykonania. Jednym z zadań było utworzenie przepływu pracy opartego na usłudze Git.
Posłuchajmy, jak zespół poszukuje lepszego sposobu współpracy. Obecnie korzystają one ze scentralizowanego systemu kontroli wersji, ale plan polega na przejściu do usługi Git, systemu rozproszonego.
Gdy Mara pracuje nad wyznaczonymi jej zadaniami, do pokoju wchodzi Andy.
Andy: Cześć Mara. Na spotkaniu przywódczym dziś rano wychowano, że nasz zespół i zespół deweloperów gier korzystają z różnych systemów kontroli wersji. Aby usprawnić udostępnianie zasobów między zespołami, poproszono nas o przejście do rozproszonego systemu kontroli wersji, który może lepiej obsługiwać współpracę.
Mara: Dobrze jest wiedzieć. Jeśli pamiętasz, umieścimy go na naszej tablicy. Obecnie używamy scentralizowanego systemu kontroli wersji. To działa świetnie dla nas teraz, ale zgadzam się, że rozproszony system kontroli wersji jest lepszym wyborem, gdy zaczniemy dzielić się między zespołami a naszym zespołem staje się większy. Jest to również zadanie na naszej tablicy, aby zwiększyć widoczność, aby wszyscy uczestnicy wiedzieli, co robią wszyscy. Myślę, że rozproszony system kontroli źródła, taki jak Git również pomoże.
Andy: Od jakiegoś czasu chcę wypróbować usługę Git. Nigdy nie wydaje mi się, że mam czas. Czy system jest trudny w obsłudze lub konfiguracji? Jeśli to ma sens, moglibyśmy zająć się tym teraz. Irytuje mnie ciągłe odkładanie rzeczy na później. Miło byłoby zobaczyć, co robią wszyscy i mieć dostęp do całego repozytorium. Na czym to wszystko polega?
Mara: Pozwól mi to wyjaśnić, a następnie możesz zdecydować, czy brzmi to jak coś, co chcemy wdrożyć od razu.
Mara i Andy podchodzą do tablicy, aby omówić system kontroli wersji.
Co to jest Git i rozproszony system kontroli wersji?
Mara: Rysunek po lewej stronie jest scentralizowaną kontrolą wersji, podobnie jak to, czego teraz używamy. Mamy centralną wersję bazy 
kodu w Kontrola wersji serwera Team Foundation (TFVC), która jest używana przez wszystkich użytkowników. Każda z nich pracuje nad plikami, które musimy zmienić, a następnie scalić je z powrotem z repozytorium głównym po zakończeniu pracy z nimi.
Andy: Tak, i to działa dla nas. Cóż, z wyjątkiem sytuacji, gdy zostałam zablokowana w tym czasie, gdy zmiana powodująca niezgodność została scalona z centralnym repozytorium.
Mara: Prawda! Użytkownik został zablokowany 
. Moglibyśmy użyć strategii rozgałęziania w systemie TFVC do rozwiązania problemu z blokowaniem, ale w naszej bieżącej konfiguracji scalanie może być bardziej skomplikowane. A kiedy mieliśmy taką zmianę 
powodującą niezgodność, nikt nie mógł wykonać żadnej pracy, dopóki nie rozwiązaliśmy tego problemu. Ten problem zawsze czai się, ponieważ wszyscy używamy tej samej kopii kodu.
Na rysunku po prawej stronie widać rozproszony system kontroli wersji. Nadal mamy centralne repozytorium 
, które jest stabilną wersją bazy kodu, ale każdy deweloper ma własną kopię 
, z której można pracować. Dzięki temu możemy eksperymentować i wypróbować różne podejścia bez wpływu na centralne repozytorium.
Rozproszona kontrola wersji zapewnia również, że tylko działający kod 
jest scalony z centralnym repozytorium. Możemy nawet skonfigurować go tak, aby nie można było scalić kodu, dopóki nie zostanie on przejrzyszony.
Co jest fajne w usłudze Azure DevOps, jest to, że działa dobrze zarówno ze scentralizowanymi systemami kontroli wersji, jak i rozproszonymi systemami kontroli wersji.
Andy: Co się stanie, gdy więcej niż jedna osoba zmieni ten sam plik?
Mara: Często usługa Git może automatycznie scalić wiele zmian. Oczywiście chcemy zawsze upewnić się, że kombinacja zmian powoduje działanie kodu. Jeśli system Git nie może automatycznie scalić zmian, oznacza konflikty bezpośrednio w plikach, więc użytkownicy mogą wybierać zmiany do zaakceptowania.
Andy: W tej chwili nasz kod jest przechowywany na naszym serwerze. Jeśli przejdziemy do korzystania z rozproszonej kontroli wersji, gdzie będzie przechowywany kod?
Mara: Cieszę się, że zapytałeś. Do tego najlepszy jest hosting.
Gdzie można hostować repozytorium?
Mara: Gdy decydujemy, gdzie hostować repozytoria, mamy kilka opcji. Na przykład możemy hostować je na serwerze lokalnym, w usłudze Bitbucket lub w usłudze GitHub. Bitbucket i GitHub to internetowe rozwiązania hostingowe. Platformy te są dostępne z dowolnego miejsca.
Andy: Czy używałeś jednego z nich?
Mara: W przeszłości korzystałem z usługi GitHub. Ma ona ważne funkcje dla deweloperów, takie jak łatwy dostęp do dzienników zmian i funkcji kontroli wersji z wiersza polecenia lub portalu online.
Andy: Jak działa usługa Git?
Jak mogę korzystać z narzędzia Git?
Mara: Jak wspomniano wcześniej, z systemami rozproszonymi deweloperzy mogą uzyskiwać dostęp do wszelkich potrzebnych plików bez wpływu na pracę innych deweloperów, ponieważ mają własną kopię repozytorium. Klon jest lokalną kopią repozytorium.
Kiedy pracujemy nad funkcjami lub poprawkami błędów, zwykle wypróbowujemy różne podejścia, aby znaleźć najlepsze rozwiązanie. Jednak wypróbowanie kodu na kopii głównej bazy kodu nie jest dobrym pomysłem, ponieważ możesz nie chcieć zachować pierwszych kilku prób.
Aby zapewnić lepszą opcję, usługa Git ma funkcję o nazwie rozgałęzianie, w której można obsługiwać dowolną liczbę kopii i scalić tylko tę, którą chcesz zachować. W ten sposób można zapewnić stabilność gałęzi głównej.
Andy: Do tej pory mam pojęcia. Jak mogę zaewidencjonować kod?
Jak moje zmiany lokalne są wprowadzane do głównej bazy kodu?
Mara: w usłudze Git domyślna gałąź lub magistrala jest zwykle nazywana .main
Gdy twój kod jest gotowy do scalenia z gałęzią main w centralnym repozytorium, które jest współużytkowane przez wszystkich deweloperów, należy utworzyć elementy nazywane żądaniem ściągnięcia. Podczas tworzenia żądania ściągnięcia informujesz innych deweloperów, że masz gotowy kod do przejrzenia i chcesz scalić go z gałęzią main . Gdy żądanie ściągnięcia zostanie zatwierdzone, a następnie scalone, stanie się częścią centralnej bazy kodu.
Na czym polega przepływ pracy dotyczący rozgałęziania?
Krok 1. Po rozpoczęciu pracy nad nową funkcją lub poprawką usterek pierwszą rzeczą, którą chcesz zrobić, jest upewnienie się, że zaczynasz od najnowszej stabilnej bazy kodu. Aby to zrobić, można zsynchronizować lokalną kopię gałęzi main z kopią na serwerze. Spowoduje to przejście do lokalnej kopii wszystkich innych zmian deweloperów, które zostały wypchnięte do main gałęzi na serwerze od ostatniej synchronizacji.
Krok 2. Aby upewnić się, że pracujesz tylko na kopii kodu, należy utworzyć nową gałąź tylko dla tej funkcji lub poprawki błędów. Jak można sobie wyobrazić, posiadanie wielu gałęzi dla wszystkich rzeczy, które robisz, może być trudne do zapamiętania, więc użycie dobrej konwencji nazewnictwa jest krytyczne.
Przed wprowadzeniem zmian w pliku należy wyewidencjonować nową gałąź, aby wiedzieć, że pracujesz nad plikami z tej gałęzi, a nie z innej gałęzi. Gałęzie można dowolnie zmieniać przez wyewidencjonowanie.
Krok 3. Teraz możesz bezpiecznie wprowadzić dowolne zmiany, ponieważ te zmiany znajdują się tylko w gałęzi. Podczas pracy możesz zatwierdzić zmiany w gałęzi, aby upewnić się, że nie utracisz żadnej pracy, i zapewnić sposób wycofywania zmian wprowadzonych we wcześniejszych wersjach. Przed zatwierdzeniem zmian należy przygotować pliki, tak aby system Git mógł rozpoznać pliki gotowe do zatwierdzenia.
Krok 4. Następnym krokiem jest wypchnięcie lub przekazanie lokalnej gałęzi do repozytorium zdalnego (takiego jak GitHub), aby inni mogli zobaczyć, nad czym pracujesz. Bez obaw, to jeszcze nie jest scalenie zmian. Zmiany można wypychać dowolnie często. W rzeczywistości jest to dobry sposób na utworzenie kopii zapasowej pracy lub umożliwienie sobie pracy z wielu komputerów.
Krok 5. Ten krok jest typowy, ale nie jest wymagany. Gdy kod działa zgodnie z potrzebami, możesz ściągnąć lub scalić gałąź zdalną main z powrotem do gałęzi lokalnejmain. Kod zawiera zmiany, których jeszcze nie ma w lokalnej gałęzi main. Po zsynchronizowaniu gałęzi zdalnej main z twoją gałęzią scal gałąź lokalną main z gałęzią roboczą i ponownie przetestuj kompilację.
Pozwoli to upewnić się, że nowa funkcja działa z najnowszym kodem, a zmiany zostaną bezproblemowo zintegrowane po przesłaniu żądania ściągnięcia.
Krok 6. Kod lokalny musi być teraz zatwierdzony i wypchnięty do hostowanego repozytorium. Procedura jest taka sama jak w krokach 3 i 4.
Krok 7. Na koniec możesz zaproponować zmiany w gałęzi zdalnej main . Aby to zrobić, rozpocznij żądanie ściągnięcia. Po skonfigurowaniu w usłudze Azure Pipelines lub innym systemie ciągłej integracji/ciągłego wdrażania ten krok wyzwala proces kompilacji i możesz obserwować zmiany przechodzące przez potok. Po pomyślnym zakończeniu kompilacji i zatwierdzeniu żądania ściągnięcia przez inne osoby kod można scalić z gałęzią zdalną main . (To nadal do człowieka, aby scalić zmiany).
Andy: To wszystko wygląda skomplikowane i trudne do nauki.
Mara: Git może wydawać się zastraszające, ponieważ jest tak potężny, ale po tym, jak wiesz przepływ, zaczyna czuć się naturalnie.
Użyjesz tylko kilku poleceń dziennie. Oto podsumowanie:
| Kategoria | Zadanie do wykonania | Polecenie |
|---|---|---|
| Zarządzanie repozytorium | Utworzenie repozytorium Git | git init |
| Pobieranie repozytorium zdalnego | git clone |
|
| Oddział | Tworzenie gałęzi | git checkout |
| Przygotowanie i zatwierdzenie zmian | Wyświetlanie zmienionych plików | git status |
| Przygotowanie plików do zatwierdzenia | git add |
|
| Zatwierdzanie plików w gałęzi | git commit |
|
| Synchronizacja zdalna | Pobieranie gałęzi z repozytorium zdalnego | git pull |
| Przekazywanie gałęzi do repozytorium zdalnego | git push |
Andy: To brzmi jak świetny punkt wyjścia. Na pewno sobie z tym poradzę. W razie potrzeby nauczę się bardziej zaawansowanych poleceń.