MCET-SEC 2: Repo

To jest druga część serii MCET-SEC, gdzie tworzę nowoczesny i wydajny toolchain dla małych ale bystrych firm z branży inżynierii oprogramowania. Zarządzam małym przedsiębiorstwem posiadającym zespół składający się z ponad dziesięciu programistów. Specjalizujemy się w platformie .NET(desktopy,web i serwisy) ale tworzymy także w nowoczesnych technologiach webowych(Angular/TS) i mobilnych(Xaramin, natywny Android i IOS). Trochę czasu minęło, od kiedy napisałem ,,Continuous Integration in .NET” i zbudowałem toolchain dla swojej firmy. Teraz pora na jego renowacje. Zacznijmy od utworzenia nowego repozytorium. Repozytorium jest powszechną wśród programistów nazwą, którą określają najważniejsze narzędzie w ich zestawie: bibliotekę kodu źródłowego. Miejsce, w którym przechowujemy owoce naszej ciężkiej pracy – tekst, który zamienia się w oprogramowanie.

Fascynujące jest spojrzenie na to jak rozwinęły się narzędzia do zarządzania kodem źródłowym na przestrzeni ostatnich lat. Pamiętam jak na początku mojej kariery korzystaliśmy z SourceSafe. Następnie pojawił się Subversion w formie VisualSVN. To było świetne narzędzie. Proste i niezawodne. Jeden centralny server, do tego lokalne repozytorium na maszynie developera. Niebawem po tym pojawił się git, który wzniósł sztukę zarządzania kodem na zupełnie nowy poziom. Innowacyjność polegała na dzieleniu się swoimi repozytoriami. Każdy programista trzymał historie projektu na swoim komputerze. Dodawał gałęzie i nowe porcje kodu lokalnie. Bardzo szybko okazało się, że brakuje czegoś więcej. Praca drużynowa i potrzeba ciągłego monitorowania jakości kodu były naturalnym bodźcem do założenia jednego centralnego servera z owocami naszej pracy. Odkryliśmy SCM-Manager: maleńki server, który pozwalał zarówno repozytorium Gita jak i SVN’a żyć równolegle ze sobą. Przyzwyczailiśmy się do wykorzystywania naszego kodu ponownie i do zachowywania go na lata – wtedy przyszedł GitHub. Narzędzie, które po raz kolejny zmieniło sposób myślenia o zarządzaniu projektem. Poza prostą funkcją do przechowywania kodu po raz pierwszy pozwalał programistom na bieżące dyskutowanie o fragmentach, które dopiero co dodali. Idea pull-requesta jako code review stała się kluczowa. Zdecydowaliśmy się używać centralnie bitbucketa, poprzez wzgląd na jednego z naszych partnerów i ogromny projekt, który dla niego wykonywaliśmy. Chcielibyśmy jednak mieć coś własnego na potrzeby innych przedsięwzięć. Rozpocząłem więc moje poszukiwania.

Rozważałem poniższe typy systemów kontroli wersji:

1. Komercyjny w chmurze
2. Lokalny(on-premise) komercyjny
3. Lokalny(on-premise) darmowy

Systemy bazujące na chmurze takie jak Github albo Bitbucket pozwalają na utworzenie prywatnych repozytoriów do przechowywania projektów. Oba są bardzo bogate jeśli chodzi o ich funkcje i wyjątkowo proste do utrzymania (tak naprawdę nie ma potrzeby, aby cokolwiek utrzymywać, ponieważ dystrybutorzy o wszystko dbają). Powyższe rozwiązania mają jednak swoje wady, które mogą być mniej lub bardziej problematyczne. W zasadzie nie masz kontroli nad tym gdzie twój kod jest fizycznie przechowywany (nie dla każdej firmy bądź klienta jest to istotne). Kolejnym problemem jest ograniczenie ilości wgrywanego kodu. Zwykle płaci się 'od programisty’. To koszt od kilku do kilkunastu dolarów miesięcznie za osobę, więc kiedy Twoja firma się rozrasta, koszty przechowywania projektów bardzo szybko się skalują.

Można próbować z tym walczyć poprzez, na przykład, lokalną instalację jednego z wybranych serwisów. BitBucket na to pozwala, oferta GitLab’a także wydaje się być interesująca. Wybierając tą drogę można mieć prawie wszystko pod kontrolą. Wszystko oprócz kosztów. Nie jest to tanie rozwiązanie, a licencja nadal naliczana jest od ilości użytkowników, więc zrezygnowaliśmy z tej opcji.

Zależy mi, żeby naprawdę wszystko było pod moją kontrolą. Jedyne co mi pozostało to rozejrzeć się wokół darmowych, open sourcowych (bądź też nie) narzędzi.

Jak zwykle chwila poszukiwań przynosiosła mi długą listę najistotniejszych dla mojej firmy cech systemu zarządzania kodem źródłowym :

• Czy ma sieciowy interfejs?
• Czy ma zintegrowaną funkcję pull request/code review?
• Czy posiada wbudowaną CI(ciągłą integrację)?
• Chcielibyśmy żeby miał AD (LDAP)
• Czy posiada zależną od repozytorium kontrolę dostępu?
• Czy posiada kontrolę dostępu zależną od gałęzi projektu?
• Czy posiada funkcję nasłuchiwania gałęzi?
• Czy posiada osobistą tablicę?(Z wszystkimi informacjami dotyczącymi danego developera)
• Czy jest łatwa w instalacji i utrzymaniu?
• Czy implementuje strategię 'sound backup’?
• Czy posiada zintegrowaną tablicę projektu?
• Czy posiada jakieś wewnętrzne narzędzi do 'road mapping’?
• Czy możemy wewnątrz robić dokumentacje wydania?

Z powyższą listą wymagań rozpocząłem poszukiwania narzędzi, które spełniałyby te kryteria. Nie mogę powiedzieć, że znalazłem ich wiele. Ostatecznie moją selekcję przetrwały tylko dwie pozycje RhodeCode i Gogs.

RhodeCode posiada wiele dodatkowych funkcjonalności takich jak czat, geolokalizacja czy wyszukiwanie pełnotekstowe. Wsparłby nas też w utrzymaniu repozytoriów bazujących na SVN I Mercurialu(nie żeby nam jakoś specjalnie na tym zależało ale lepiej mieć niż nie mieć). Dodatkowo nazwa głównego programisty wyglądała całkiem ładnie(wpisałem Marcin). Jako, że w mojej firmie postawiliśmy na Windowsa to naturalnym wyborem dla nas byłby Windows Server jako host dla systemu kontroli wersji. To jest największy problem. RhodeCode jest oprogramowaniem Linuxowym. Praktycznie nie da sie zainstalować go na Windowsie. Można postawić całkowicie wirtualną maszynę I na niej ustawić Hyper-V, co z resztą zrobiliśmy i nawet działało. Integracja z AD musiała zostać zrobiona w surowym pliku tekstowym(no raczej!). RhodeCode posiada dualistyczną licencję. Z jednej strony jest płatny enterprise, a z drugiej uboższy community. W trakcie moich rozważań wygasła mi płatna licencja i musiałem ustawiać RhodeCode’a w wersji darmowej. Jest całe szkolenie jak to zrobić. Zaloguj się na maszynę linuxową, wpisz parę komend tu I tam, zresetuj kilka razy.. Jak można się domyśleć wcale nie chciało działać. Oczywiście, prawdopodobnie by zadziałało gdybym poświęcił na to więcej czasu ale miałem już dosyć. Zdecydowałem się wypróbować gogsa.

Instalacja przebiegła bardzo łatwo. Wystarczy upewnić się, że Git jest w odpowiedniej ścieżce systemowej, pobrać ZIP’a i trzymać się dokumentacji. Pobrałem, wypakowałem, a następnie w wierszu poleceń użyłem komendy ‘gogs web’. Konfiguracja LDAP  była trochę bardziej zagmatwana(jak zwykle) ale udało się ją zrobić całkowicie z internetowego panelu administratora:

Nie zapomnij, że będziesz musiał stworzyć użytkownika w Gogs admin panelu, aby otrzymać dostęp do Gogsa, który używa twojego użytkownika AD. Konfiguracja SSL to kwestia edycji pliku gogs’a app.ini, zmiany prokokołu, ustawieniu certyfikatu oraz kluczowych ścieżek do plików, tak jak jest to opisane w Gogs FAQ. Ostatnią konfiguracją, którą wykonałem było wyłączenie odkrywania funkcjonalności dla anonimowych użytkowników(chcę, aby moje repozytoria były dostępne na zewnątrz mojej organizacji ale nie nasłuchujące na moich programistów). Można łatwo to ustawić w app.ini używając:

[service]
REQUIRE_SIGNIN_VIEW = true

Voila! Wszystko gotowe. Będę informował o tym jak rozwiązanie przyjmuje się pośród moich programistów.