Czy możemy się czegoś nauczyć ze sposobu wprowadzania zmian na tej platformie?

Rozwój wymusza specjalne podejście

W ciągu ostatniego roku GitHub podwoił liczbę programistów tworzących główną aplikację GitHub.com. Chociaż wydaje się to czysto pozytywną rzeczą, to jest tak tylko na pierwszy rzut oka. Dwukrotny wzrost liczby osób tworzących podstawowe oprogramowanie platformy ujawnił pewne problemy w zakresie narzędzi jakimi zespół deweloperów się posługuje. Oprogramowanie, które GitHub z powodzeniem stosował jeszcze rok temu, teraz nie pozwala już pracować z taką samą wydajnością. Chociaż sam GitHub był fantastycznym narzędziem do wprowadzania zmian w GitHub, narzędzia do wdrażania i koordynacji nie cieszyły się już tak entuzjastyczną oceną. Jednym z tych obszarów były wdrożenia.

GitHub.com jest wdrażany głównie za pomocą chatopsów (operatorów chatów) przy użyciu modelu wdrażania gałęzi (wdrażane są poszczególne gałęzie, przed mergiem z główną gałęzią). Oznaczało to, że programiści mogą dodawać zmiany do kolejki, sprawdzać stan kolejki i organizować grupy pull requestów, które mają być wdrożone i scalone. To wszystko działało za pomocą chatopsów w Slacku w pokoju o nazwie #dotcom-ops. Chociaż jest to bardzo prosty system, zaczął powodować zamieszanie podczas monitorowania wdrożenia, ponieważ pojedynczy pokój rozmów zarządzał kolejką, wdrażaniem i wieloma innymi zadaniami dla wielu osób w tym samym czasie. Nagle ten kanał, który niegdyś był centralną częścią kluczowego systemu informacyjnego, został przytłoczony ilością przepychanych przez niego informacji. Deweloperzy nie mogli już śledzić ich zmian w systemie, co skutkowało zmniejszoną wydajnością programistów. Oprócz kuli ziemskiej na głównej stronie GitHuba trzeba więc było zrobić coś więcej.

Zmiany

Na początku lata 2020 roku GitHub postanowił całkowicie zmienić sposób, w jaki monitorowane jest wdrażanie zmian w witrynie GitHub.com. Mając na uwadze problem - a mianowicie wieloetapowy, obfitujący w informacje proces wdrażania za pośrednictwem czatów - wyznaczono kilka głównych celów:

Uproszczenie wdrażania przez programistów

Jednym z głównych problemów, które napotkano w poprzednim systemie, było to, że wdrożenia były śledzone w wielu różnych komunikatach w kanale Slack. To utrudniało poskładanie różnych wiadomości składających się na jednego deploy’a. Czasami między kolejnymi komunikatami z systemu wdrażania może znajdować się nawet kilkaset komunikatów wysyłanych przez deweloperów.

Canary stage

Przypomnijmy, że canary test czy canary deployment polega na zaktualizowaniu programu u części użytkowników „po cichu” i sprawdzenie jak to u nich działa – w razie bugów można się z tej aktualizacji w miarę szybko i bezproblemowo wycofać. Drugim głównym problemem GitHuba było to, że używano wprawdzie canary stage, ale to tylko do 2% ruchu na GitHub.com. Oznaczało to, że istniała cała masa problemów, które nigdy nie zostałyby złapane na etapie canary stage przed całkowitym wdrożeniem do produkcji. Mając to na uwadze, postanowiono wprowadzić drugi etap canary z wyższym procentem pokrycia, aby można było wychwycić więcej problemów na wcześniejszych etapach.

Ustalono pierwszy etap na 2% i drugi na 20%.

Automatyzacja

Ostatnią kwestią było to, że programiści musieli siedzieć przy wdrożeniu i pomagać we wdrażaniu go na każdym etapie. Oznaczało to, że programiści wielokrotnie majstrowali przy poleceniach chatopsa przy każdym wdrożeniu i często robili to błędnie. Zautomatyzowano więc ten proces.

Sprawdź oferty pracy na TeamQuest

Rozwiązanie

Priorytetem było dodanie możliwości zautomatyzowania całej sekwencji wdrażania za pomocą jednego polecenia chatops, zamiast uruchamiania wielu poleceń w celu wdrożenia. W rezultacie zastosowano 2% canary stage 1, 20% canary stage 2, wdrożenie produkcyjne (deploy to production) i etap gotowości do scalenia (ready to merge) - oddzielone automatycznymi, 5-minutowymi licznikami. Wreszcie, wskaźnik został zautomatyzowany, aby przejść przez model danych po zakończeniu bramek czasowych i wdrożeniu etapów.

Zostało to połączone z tradycyjnymi chatopsami, które znali już programiści GitHuba. Zamiast śledzić różne wiadomości w zatłoczonym kanale Slack, można teraz przejść do skonsolidowanego interfejsu użytkownika. Programiści mogą zobaczyć postęp zautomatyzowanego wdrożenia. Możesz na przykład zobaczyć, że każdy etap tego wdrożenia ma automatyczny 5-minutowy licznik czasu między etapami i możliwość wstrzymania wdrożenia, aby dać deweloperowi więcej czasu na przetestowanie. W przypadku, gdy coś było nie tak, istnieje sposób na szybkie przywrócenie lub cofnięcie zmian.

Wreszcie cały system można monitorować i uruchamiać ze Slacka - tak jak poprzednio. Programiści w końcu zwykle chcą rozpocząć wdrażanie, a następnie monitorować je w komponencie interfejsu użytkownika.