Git to repozytorium kodu a repozytorium kodu to jedno z podstawowych narzędzi pracy programisty. Dzisiaj pół internetu pisze, że GitLab – serwis do hostowania repozytoriów git – zaliczył poważną wpadkę. Trudno, zdarza się ale jakie można z tego wyciągnąć wnioski?
Single Point Of Failure
Centralne repozytorium kodu ma tą wielką zaletę, że jest centralne. SVN-y, SourceSafe-y i inne tego typu repozytoria kodu mają wielką zaletę – jedno źródło prawdy. To też najsłabsza strona – bo jak padnie serwer to nie ma nic. Na komputerach programistów pozostanie wprawdzie kod źródłowy ale bez jakiejkolwiek historii. Na ten wypadek warto mieć zbudowany odpowiedni plan backupu a właściwie kilku backupów – w chmurze, w szafie ogniotrwałej, offsite. Warto by było od czasu do czasu sprawdzić czy z backupu da się cokolwiek odzyskać. Generalnie w sytuacji awarii serwera odgrzebujemy backup, przywracamy repozytorum i pracujemy dalej no chyba, że padł sprzęt a my nie mamy zapasu, wtedy zamawiamy nowy, przywracamy co trzeba i pracujemy dalej. Już po kilku godzinach lub dniach spokojnie sobie pracujemy. Czy nie da się tego jakoś usprawnić?
Git na ratunek!
Dzisiejsza awaria GitLaba przeraziła całkiem sporą część internetu. Nie ma się co dziwić, bo wyobraź sobie, że nagle nie masz dostępu do swojego repozytorium. Mi się taka akcja zdarzyła w najgorszym możliwym momencie – w czasie wdrożenia przy sporej presji czasowej. Nagle repozytorium git-owe padło a dokładniej padł vpn do serwera ileś tam kilometrów dalej. Dwie osoby pracują nad kodem – wiadomo, ostatnie poprawki – czas ucieka, zmęczenie doskwiera a tu co? mamy ręcznie kod mergować? Na szczęście git to rozproszone repozytorium kodu a nie jak wspomniane w pierwszym akapicie „centralne repozytoria”. Rozproszone repozytorium oznacz tyle, że masz lokalną kopię całego repozytorium na komputerze. To oznacz, że bardzo szybko możesz postawić inne repozytorium. W moim przypadku sprowadziło się to do założenia repozytorium na bitbuckecie (bo tam można za darmo hostować prywatne repozytorum) a potem wykonania dwóch komend:
[code]
git remote add backup git@bitbucket.org:.../.....git
git push backup master
[/code]
To spowodowało, że w chmurze pojawiła się pełna kopia repo i mogliśmy spokojnie pracować dalej. Cała operacja trwała może 5 minut razem z założeniem konta i wysłaniem danych.
Czy awaria gita to jakaś tragedia?
No właśnie, wracając do samej awarii gitlab-a (ale i innch, githuba, bitbucket-a i tych wszystkich tajnych firmowych „bezpiecznych” repozytoriów), jeśli tylko nasze repozytorium jest rozproszone to w 5 minut jesteśmy wstanie postawić kopię i pracować dalej. Taka awaria będzie dla nas mikro przeszkodą a nie tragedią blokującą pracę na godziny a czasem nawet na dni. To jest siła posiadania kopii repozytorium lokalnie…
… z małym zastrzeżeniem, jeśli regularnie commitujemy i regularnie pushujemy do zewnętrznego repozytorium.
