GitHub driven business

Ktokolwiek kto miał kiedyś do czynienia z programistami zdaje sobie sprawę z tego jakim wyzwaniem jest nakłonienie nas do robienia czegokolwiek poza programowaniem (choć ostatnimi laty zdaje się, że się to zmienia). Nie dziwne więc, że repozytoria kodu ochoczo zaczęły być wykorzystywane do coraz większej ilości rzeczy, które kodowaniem nie są, ale pod płaszczem kontroli wersji przypominają je wystarczająco.

Zapraszam więc do Świata-as-Code. Documentation-as-Code, Infrastructure-as-Code, Configuration-as-Code, Process-as-Code. Niedawno, przy okazji boomu na LLMy, do tego grona dołączyły podejścia typu Prompts-as-Code. Ale to w zasadzie i tak jest tylko wierzchołek góry lodowej, bo kiedy mówimy o GitHubie, to możliwości jest znacznie więcej, ale o tym za chwilę.

Litościwie dla samego siebie nie będę się cofał do genezy systemów wersjonowania. Powiem jedynie, gwoli wyjaśnienia - co w praktyce znaczy “-as-Code”? Zasadniczo odnosić się to może do dwóch aspektów. Pierwszy (wydaje się, że wiodący) to sposób przechowywania treści, pozwalający na jej wersjonowanie, kooperację z innymi osobami przy edycji oraz przechowywanie historii zmian. Drugi, to aspekt funkcjonalnościowy, gdzie np. w Infrastructure-as-Code, kod służy do zarządzania infrastrukturą, co “standardowo” jest obsługiwane innymi narzędziami.

W zasadzie przy odrobinie chęci można GitHubem zastąpić większość potrzeb chmurowych przeciętnej firmy.

Mamy więc dwa zasadnicze plusy - pierwszy, to przeniesienie konkretnego obszaru inżynierii oprogramowania (infrastruktury, CI/CD, procesów, zasobów), do obszaru w którym programiści są ekspertami. Drugi (wydaje się, że globalnie istotniejszy) to wykorzystanie kultury pracy z kodem, wytworzonej na przestrzeni ostatnich dziesięcioleci w innych obszarach, mniej albo bardziej powiązanych z kodowaniem. Na podstawowym poziomie, dla średnio ogarniętego programisty plusy są oczywiste. Określona wersja aplikacji, operująca określonymi bibliotekami, na określonych środowiskach uruchomieniowych i oferująca określone funkcjonalności. Rozsądne jest założenie, że trzymanie definicji infrastruktury, procesów i dokumentacji w tym samym miejscu, wersjonowane razem, ogranicza znacznie niebezpieczeństwo dezaktualizacji. Idąc dalej - czy można trzymać w repozytoriach decyzje architekturowe? No można. Konfigurację? Pod pewnymi założeniami (łatwość edycji w locie, ukrywanie sekretów, etc) - można. Narzędzia i szeroko pojęte prompty do naszych magicznych ejajów - można.

W tym miejscu dodam jeszcze, że jeśli jesteś programistą, albo przynajmniej piszesz jakiś kod, i to czytasz, to zainteresuj się (jeśli jeszcze tego nie zrobiłeś) Conventional Commits oraz GitHub flow. Wiem, że duża część z Was teraz mnie posądzi o ograniczanie ich kreatywności i zajmowanie się pierdołami, zamiast poważnych spraw, ale zaufajcie mi. Parafrazując wieszcza - “procesy i standardy, ile was trzeba cenić ten tylko się dowie, kto was stracił”.

Ale to wszystko to w zasadzie poruszanie sie w obszarze konkretnego projektu programistycznego. A nic nie stoi na przeszkodzie, aby z tej bańki wyjść. GitHub to również rozbudowane wersjonowanie, kontrola i integracja procesów dostarczania w zasadzie gdziekolwiek, komentarze, ticketowanie, historia zmian, grupy użytkowników, uprawnienia, zaawansowane zabezpieczenia na na wielu warstwach, dostęp z każdego miejsca z internetem i funkcjonalność GH Pages. W zasadzie przy odrobinie chęci można tym zastąpić większość potrzeb chmurowych przeciętnej firmy.

Potrzebujesz firmowej dokumentacji - możesz używać Confluence’a, bądź jakiejkolwiek jego alternatywy, ale możesz też utrzymywać dokumentację w plikach MD w repozytorium GitHub. Czytanie MD w GitHubie jest wygodne, jest drzewo treści, wersjonowanie i historia zmian, zespoły i urawnienia. Jedyną poważną przeszkodą może być przekonanie Karen do pisania krzaczków zamiast wyklikania stylu nagłówka.

Łatwo jest z resztą używać repozytorium w GH po prostu jako notatnika w chmurze, do którego mamy dostęp wszędzie, za darmo. Względnie jako źródło plików dla notatnika typu Obsidian, operującego na plikach MD. Za każdy sensowny notatnik chmurowy trzeba płacić naszą krwawicą - za ten nie. Mało tego, wystarczy po prostu pobrać obsydianową wtyczkę Fit - Obsidian Plugin i Twoje repozytorium po szybkiej konfiguracji może stać się Twoim obsydianowym vaultem:

1. Tworzymy nowe, prywatne repozytorium , visibility - private, no template, no README, no license, no gitignore
2. Tworzymy nowy fine-grained token scope na nowo stworzone repo, uprawnienia Contents - Read and Write
3. Instalujemy i konfigurujemy wtyczkę używając tych danych, na każdym urządzeniu gdzie mamy zainstalowanego Obsidiana
4. Oszczędzamy miesięcznie 5$ (względnie, mamy funkcjonalność, której byśmy nie mieli, bo nam szkoda 5$)

A jak już tak się do tego GitHuba przykleiliśmy, to możemy przy okazji skorzystać z jego peryferiów zamiast utrzymywać inne dodatkowe subskrypcje. Potrzebujesz wyhostować prostą stronę z dokumentacją OpenAPI/Swagger, z wizytówką, z prototypem - używasz GitHub Pages i wiatr z głowy. A przy odrobinie szczęścia i kreatywności i proste funkcjonalności backendowe uda się z tym spiąć. Potrzebujesz prostego systemu do zarządzania zadaniami - GitHub Issues. Nie wspominając o szerokich możliwościach operacyjnych GitHub Actions.

Ciekawym podejściem do tematu swego czasu było upublicznienie projektów nowych ustaw podatkowych przez Konfederację w trzech dedykowanych, publicznych repozytoriach GH - Projekty Ustaw. Odkładając na bok to, czy ugrupowanie popieramy, czy nie, warto docenić innowacyjność pomysłu, który zarówno dodaje nową cegiełkę do transparentności procesu jak i podejmuje próbę demokratyzacji tworzenia takich dokumentów prawnych. (Nie wspominając również o tym, że pomysł nie odbił się szerokim echem i był raczej zagrywką PRową)

Grzech też na końcu nie wspomnieć o inicjatywach takich jak ten Starcraft Soundboard - źodyn nam nie zabroni ustawić sobie “not enough minerals” na dźwięk powiadomienia wiadomości. Nostalgia dla ludzi w tak podeszłym wieku jak ja jest bezcenna.

I kończąc już ten przydługi wywód, jeśli miałbym go zamknąć jakąkolwiek puentą, to niech będzie jedna - nauczcie się używać, i używajcie GitHuba na co dzień, nawet, jeśli nie macie nic wspólnego z programowaniem, bo to jest po prostu wygodne narzędzie. W dobie LLMów prawdopodobnie jego dostępność i używalność jeszcze się zwiększą, a kultura pracy, wyrobiona przez lata w ramach rozwiązań opartych o GIT, jest po prostu wartościowa.