W GitLab przetwarzamy poprawki oprogramowania na dwa sposoby: ręcznie i automatycznie. Czytaj dalej, aby dowiedzieć się o pracy menedżera wersji polegającej na tworzeniu i dostarczaniu ważnych aktualizacji poprzez automatyczne wdrażanie na gitlab.com, a także poprawek, z którymi użytkownicy mogą pracować nad własnymi instalacjami.
Polecam ustawić przypomnienie na swoim smartwatchu: co miesiąc 22-go użytkownicy pracujący z GitLabem w swoich placówkach mogą zobaczyć aktualizacje aktualnej wersji naszego produktu. Comiesięczne wydanie zawiera nowe funkcje, rozwinięcia istniejących i często pokazuje końcowy wynik próśb społeczności o narzędzia lub fuzje.
Jednak, jak pokazuje praktyka, tworzenie oprogramowania rzadko jest pozbawione wad. Po wykryciu błędu lub luki w zabezpieczeniach menedżer wersji w zespole dostarczającym tworzy łatkę dla naszych użytkowników wraz z ich instalacjami. Gitlab.com jest aktualizowany podczas procesu CD. Nazywamy to automatycznym wdrażaniem procesu CD, aby uniknąć pomyłek z funkcją CD w GitLab. Proces ten może uwzględniać sugestie pochodzące z żądań ściągnięcia przesłanych przez użytkowników, klientów i nasz wewnętrzny zespół programistów, dzięki czemu rozwiązanie nudnego problemu wydawania poprawek można rozwiązać na dwa bardzo różne sposoby.
«Dbamy o to, aby wszystko, co tworzą programiści, było codziennie wdrażane we wszystkich środowiskach, zanim udostępnimy je na GitLab.com„, wyjaśnia , Starszy Menedżer Techniczny, Dział Infrastruktury. "Pomyśl o wydaniach swoich instalacji jak o migawkach wdrożeń gitlab.com, dla których dodaliśmy osobne kroki, aby utworzyć pakiet, aby nasi użytkownicy mogli go używać do instalowania w swoich instalacjach".
Niezależnie od błędu lub luki, klienci gitlab.com otrzymają poprawki wkrótce po ich opublikowaniu, co jest zaletą zautomatyzowanego procesu CD. Poprawki dla użytkowników posiadających własne instalacje wymagają osobnego przygotowania przez menadżera wydań.
Zespół dostaw ciężko pracuje, aby zautomatyzować większość procesów związanych z tworzeniem wydań w celu ograniczenia (średni czas do produkcji, tj. czas spędzony na produkcji), okres czasu od przetworzenia żądania połączenia przez programistę do wdrożenia na gitlab.com.
«Celem zespołu dostaw jest upewnienie się, że możemy działać szybciej jako firma lub przynajmniej sprawić, by dostawcy pracowali szybciej, prawda?, mówi Marin.
Zarówno klienci gitlab.com, jak i użytkownicy ich instalacji odnoszą korzyści z wysiłków zespołu dostawczego mających na celu skrócenie czasu cykli i przyspieszenie wdrożeń. W tym artykule wyjaśnimy podobieństwa i różnice między tymi dwiema metodami. , a także opiszemy, w jaki sposób nasz zespół dostaw przygotowuje poprawki dla użytkowników pracujących na swoich obiektach, a także w jaki sposób zapewniamy, że gitlab.com jest aktualna dzięki automatycznemu wdrażaniu.
Co robi menedżer wersji?
Członkowie zespołu miesięcznie nasze wydania dla użytkowników w ich obiektach, w tym poprawki i aktualizacje zabezpieczeń, które mogą pojawić się pomiędzy wydaniami. Są także odpowiedzialni za kierowanie przejściem firmy na zautomatyzowane, ciągłe wdrażanie.
Wersje do samodzielnej instalacji i wydania gitlab.com korzystają z podobnych przepływów pracy, ale działają w różnym czasie, wyjaśnia Marin.
Przede wszystkim release manager, niezależnie od typu wydania, dba o to, aby GitLab był dostępny i bezpieczny od momentu uruchomienia aplikacji na gitlab.com, w tym dba o to, aby te same problemy nie trafiły do infrastruktury klientów wraz z ich własne możliwości.
Gdy błąd lub luka zostanie oznaczona w GitLabie jako naprawiona, menedżer wersji musi ocenić, czy zostanie ona uwzględniona w łatkach lub aktualizacjach zabezpieczeń dla użytkowników wraz z ich instalacjami. Jeśli uzna, że błąd lub podatność zasługuje na aktualizację, rozpoczynają się prace przygotowawcze.
Menedżer wersji musi zdecydować, czy przygotować poprawkę i kiedy ją wdrożyć – a to w dużym stopniu zależy od kontekstu sytuacji.w międzyczasie maszyny nie radzą sobie tak dobrze z zarządzaniem kontekstem jak ludzie– mówi Marin.
Wszystko zależy od poprawek
Czym są łatki i dlaczego ich potrzebujemy?
Menedżer wersji decyduje, czy wypuścić poprawkę, na podstawie wagi błędu.
Błędy różnią się w zależności od ich wagi. Zatem błędy S4 lub S3 mogą mieć charakter stylistyczny, np. przemieszczenie pikseli lub ikon. Jest to nie mniej ważne, ale nie ma znaczącego wpływu na niczyją pracę, co oznacza, że prawdopodobieństwo, że zostanie utworzona poprawka dla takich błędów S3 lub S4, jest małe, wyjaśnia Marin.
Jednakże luki S1 lub S2 oznaczają, że użytkownik nie powinien aktualizować oprogramowania do najnowszej wersji lub występuje istotny błąd wpływający na przepływ pracy użytkownika. Jeśli są one uwzględnione w module śledzącym, spotkało się z nimi wielu użytkowników, więc menedżer wersji natychmiast zaczyna przygotowywać poprawkę.
Gdy łatka na luki S1 lub S2 będzie gotowa, menedżer wydań zaczyna ją wypuszczać.
Na przykład łatka GitLab 12.10.1 została utworzona po zidentyfikowaniu kilku problemów blokujących, a programiści naprawili podstawowy problem, który je powodował. Menedżer wydania ocenił poprawność przypisanych poziomów ważności i po potwierdzeniu został uruchomiony proces wypuszczenia poprawki, która była gotowa w ciągu XNUMX godzin od wykrycia problemów blokujących.
Kiedy gromadzi się dużo poprawek S4, S3 i S2, menedżer wersji sprawdza kontekst, aby określić pilność wydania poprawki, a kiedy zostanie osiągnięta określona liczba poprawek, wszystkie są łączone i wydawane. Poprawki wprowadzone po wydaniu lub aktualizacje zabezpieczeń są podsumowane w postach na blogu.
Jak menedżer wersji tworzy poprawki
Do generowania poprawek używamy GitLab CI i innych funkcji, takich jak nasze ChatOps. Menedżer wersji inicjuje wydanie poprawki, aktywując zespół ChatOps na naszym kanale wewnętrznym #releases w Slacku.
/chatops run release prepare 12.10.1ChatOps działa w ramach Slacka, wyzwalając różne zdarzenia, które są następnie przetwarzane i wykonywane przez GitLab. Na przykład zespół dostaw skonfigurował ChatOps w celu automatyzacji różnych rzeczy w celu wydawania poprawek.
Gdy menedżer wersji uruchomi zespół ChatOps w Slack, reszta pracy dzieje się automatycznie w GitLab przy użyciu CICD. Podczas procesu wydawania wersji istnieje dwukierunkowa komunikacja pomiędzy ChatOps w Slack i GitLab, gdy menedżer wersji aktywuje niektóre główne etapy procesu.
Poniższy film przedstawia techniczny proces przygotowania łatki dla GitLaba.
Jak działa automatyczne wdrażanie na gitlab.com
Proces i narzędzia używane do aktualizacji gitlab.com są podobne do tych używanych do tworzenia łatek. Aktualizacja gitlab.com wymaga mniej pracy ręcznej z punktu widzenia menedżera wersji.
Zamiast przeprowadzać wdrożenia za pomocą ChatOps, korzystamy z funkcji CI m.in. , za pomocą którego menedżer wersji może zaplanować wykonanie określonych działań w wymaganym czasie. Zamiast procesu ręcznego istnieje potok uruchamiany okresowo co godzinę, który pobiera nowe zmiany wprowadzone w projektach GitLab, pakuje je i planuje wdrożenie, a także automatycznie uruchamia testy, kontrolę jakości i inne niezbędne kroki.
„Dlatego przed gitlab.com mieliśmy wiele wdrożeń działających w różnych środowiskach, a gdy te środowiska były w dobrym stanie, a testy wykazały dobre wyniki, menedżer wersji rozpoczyna działania związane z wdrażaniem gitlab.com” – mówi Marin.
Technologia CICD do obsługi aktualizacji gitlab.com automatyzuje cały proces do tego stopnia, że menedżer wersji musi ręcznie uruchomić wdrożenie środowiska produkcyjnego na gitlab.com.
Marin szczegółowo opisuje proces aktualizacji gitlab.com w poniższym filmie.
Co jeszcze robi zespół dostawczy?
Główna różnica między procesami aktualizacji gitlab.com a wydawaniem poprawek klientom we własnym zakresie polega na tym, że ten drugi proces wymaga więcej czasu i większej pracy ręcznej ze strony menedżera wydań.
„Czasami opóźniamy udostępnienie klientom poprawek wraz z ich instalacjami ze względu na zgłoszone problemy, problemy z narzędziami oraz dlatego, że istnieje wiele niuansów, które należy wziąć pod uwagę przy wydawaniu pojedynczej poprawki” – mówi Marin.
Jednym z krótkoterminowych celów zespołu dostarczającego jest zmniejszenie ilości ręcznej pracy menedżera wersji w celu przyspieszenia wydania. Zespół pracuje nad uproszczeniem, usprawnieniem i automatyzacją procesu wydawania wersji, co pomoże uzyskać poprawki problemów o niskiej wadze (S3 i S4, około. tłumacz). Koncentrowanie się na szybkości jest kluczowym wskaźnikiem wydajności: konieczne jest skrócenie MTTP – czasu od otrzymania żądania połączenia do wdrożenia wyniku na gitlab.com – z obecnych 50 godzin do 8 godzin.
Zespół dostarczający pracuje również nad migracją gitlab.com do infrastruktury opartej na Kubernetes.
Uwaga redaktora: Jeżeli słyszałeś już o technologii Kubernetes (a nie mam wątpliwości, że tak), ale jeszcze nie dotknąłeś jej rękami, polecam wziąć udział w intensywnych kursach online , który odbędzie się w dniach 28-30 września, oraz który odbędzie się w dniach 14-16 października. Dzięki temu będziesz mógł bezpiecznie poruszać się po technologii i pracować z nią.
Są to dwa podejścia, które mają ten sam cel: szybkie dostarczanie aktualizacji, zarówno dla gitlab.com, jak i dla klientów w ich placówkach.
Jakieś pomysły lub rekomendacje dla nas?
Każdy może przyczynić się do GitLab i czekamy na opinie naszych czytelników. Jeśli masz jakiś pomysł na nasz zespół dostawczy, nie wahaj się z wypowiedzeniem team: Delivery.
Źródło: www.habr.com