Proces zarządzania wydaniami dla zespołów wydających często

Proces zarządzania wydaniami to zestaw kroków, który prowadzi zmianę od “scalona” do “działa na produkcji i jest wyjaśniona ludziom, których dotyczy”. Dla zespołu, który wydaje często, sprowadza się do siedmiu kroków: zaplanować zakres, odizolować zmianę, zbudować i przetestować, zatwierdzić, wdrożyć i zweryfikować, zakomunikować oraz podsumować. Każdy krok potrzebuje jednego wskazanego właściciela i jednego kryterium wyjścia, bo inaczej po cichu przestaje się dziać.

Ten przewodnik zakłada zespół od 5 do 50 inżynierów, który wdraża co tydzień lub codziennie i chce, by proces nie wchodził w drogę.

Czym jest proces zarządzania wydaniami?

To powtarzalna ścieżka, którą zmiana przechodzi, by dotrzeć do użytkowników: zakres, budowa, testy, zatwierdzenie, wdrożenie, weryfikacja, ogłoszenie i spojrzenie wstecz. Sens spisania go polega na tym, że każde wydanie idzie tą samą ścieżką, więc osoba na urlopie, nowy pracownik albo inżynier na dyżurze o drugiej w nocy mogą go przeprowadzić, nie pytając nikogo, jak to działa.

Jakie są rodzaje zarządzania wydaniami?

Są trzy praktyczne rodzaje: ciągłe wdrażanie, wydania planowe i regulowane zarządzanie zmianą. Różnią się tym, ile dzieje się przed wydaniem i ile jest zautomatyzowane. Ciągłe wdrażanie wypuszcza każdą scaloną zmianę, wydania planowe grupują zmiany w pociąg, a regulowane zarządzanie zmianą dodaje formalne zatwierdzenie i ślad audytowy.

Większość zespołów to mieszanka. Produkt SaaS może wdrażać ciągle, podczas gdy jego aplikacja mobilna wychodzi tygodniowym pociągiem, a jedna usługa płatności, która interesuje audytorów, idzie według formalnego rekordu zmiany. Wybierajcie rodzaj dla usługi, nie dla firmy. Tam, gdzie zmiany są ujawniane stopniowo, wydanie i ogłoszenie stają się osobnymi zdarzeniami, a ten przypadek opisują release notes przy flagach funkcji.

Jakie są obowiązki release managera?

Release manager odpowiada za ścieżkę, którą zmiana przechodzi na produkcję. Prowadzi kalendarz wydań, decyduje, czy zmiana jest gotowa, przeprowadza lub nadzoruje wdrożenie, podejmuje decyzję o wycofaniu, dba, by użytkownicy zostali poinformowani, i prowadzi podsumowanie po wszystkim.

Przed wydaniem potwierdza zakres i sprawdza, czy każda ryzykowna zmiana ma ścieżkę wycofania. W trakcie prowadzi listę kontrolną wdrożenia, obserwuje pierwsze minuty metryk produkcyjnych i wcześnie wywołuje wycofanie. Potem potwierdza, że notatki wyszły, i zapisuje, co poprawić w procesie.

W małym zespole rotujcie tę rolę co tydzień i napiszcie listę kontrolną tak, by nikt nie potrzebował wiedzy plemiennej. Monorepo z wieloma niezależnie wydawanymi pakietami zwykle potrzebuje jednego właściciela wydań na pakiet, bo inaczej rola staje się wąskim gardłem.

Jakie są kluczowe wskaźniki zarządzania wydaniami?

Śledźcie metryki dostarczania oprogramowania DORA i dodajcie jedną własną: jak długo trwa poinformowanie użytkowników. Badania DORA wskazują pięć metryk, podzielonych na przepustowość (czas realizacji zmiany, częstotliwość wdrożeń, czas odzyskiwania po nieudanym wdrożeniu) i niestabilność (wskaźnik awaryjności zmian, wskaźnik poprawek po wdrożeniu).

Poradnik DORA definiuje je prostymi słowami (dora.dev, software delivery metrics):

Starsze materiały wymieniają cztery klucze i nazywają odzyskiwanie “time to restore”. Obecny poradnik używa pięciu powyższych.

Ten sam poradnik ostrzega przed traktowaniem tych metryk jak celów. Wyznaczenie celu w rodzaju “wszystko wdraża się kilka razy dziennie do końca roku” zachęca zespoły do naginania liczb, a metryki mają być czytane na aplikację lub usługę, a nie uśredniane w całej firmie. Jego praktyczna rada na poprawę wszystkich jest taka, by zmniejszać rozmiar każdej zmiany, bo mniejsze zmiany łatwiej przejrzeć, przeprowadzić przez pipeline i się po nich odzyskać.

Jak komunikacja wydania pasuje do procesu zarządzania wydaniami?

To krok szósty i ma właściciela oraz kryterium wyjścia jak każdy inny krok: notatki opublikowane tam, gdzie czytają użytkownicy, i zespoły wewnętrzne poinformowane. Zespoły pomijają go najczęściej, bo narzędzia do wdrożeń raportują sukces w chwili, gdy kod jest na żywo.

Najtańszy sposób na utrzymanie tego kroku w harmonogramie to pisanie wpisu, gdy zmiana jest scalana, a nie gdy wydanie wychodzi. Pull request już zawiera tytuł, autora, powiązane issue i kontekst. Szkic zbudowany z niego się redaguje, a nie pisze z pamięci tydzień później. Taka jest idea automatyzacji changelogu: wyprowadzić szkic przy scaleniu, wstrzymać go do zatwierdzenia przez człowieka, a potem opublikować wszędzie z jednego źródła. Changeloop działa w ten sposób, tworząc szkice wpisów ze scalonych pull requestów za pomocą AI i wstrzymując je do zatwierdzenia, zanim cokolwiek zostanie opublikowane.

Warto z góry zaplanować dwa warianty. Wsparcie i sprzedaż potrzebują innej noty niż klienci, do czego służą wewnętrzne notatki wydania. Wydanie wywołane incydentem nie ma czasu na zwykłą pętlę szkicowania, więc miejcie gotowy krótki szablon, jak opisują awaryjne release notes. Szablon release notes daje wam punkt wyjścia dla wersji skierowanej do klientów.

Jak utrzymać lekki proces?

Zautomatyzujcie każde kryterium wyjścia, które może sprawdzić maszyna, a ludziom zostawcie decyzje wymagające osądu. Zielony pipeline, znacznik wdrożenia na dashboardach i szkic wpisu changelogu na każdy scalony pull request da się sprawdzić. To, czy plan wycofania jest wiarygodny albo czy notatki mają sens dla klienta, wymaga człowieka.

Aby przetestować proces, wybierzcie wydanie z zeszłego miesiąca i zapytajcie, czy ktoś spoza zespołu potrafiłby na podstawie samego zapisu powiedzieć, co wyszło, kto to zatwierdził, jak to zweryfikowano i kiedy poinformowano użytkowników. Każda luka to wasze następne usprawnienie.

FAQ

Czym różni się zarządzanie wydaniami od zarządzania zmianą? Zarządzanie wydaniami sprawia, że zestaw zmian jest zbudowany, przetestowany, wdrożony i ogłoszony. Zarządzanie zmianą w rozumieniu ITIL to proces zatwierdzania i oceny ryzyka wokół każdej zmiany. Zespoły, które wydają często, włączają zatwierdzanie w code review i automatyczne kontrole.

Jak często powinniśmy wydawać? Tak często, jak pozwalają wasze testy i ścieżka wycofania, co dla wielu zespołów webowych oznacza codziennie lub częściej. Wskazówka DORA to zmniejszać rozmiar każdej zmiany, bo małe zmiany łatwiej przejrzeć i się po nich odzyskać.

Czy małe zespoły potrzebują release managera? Potrzebują obowiązków, ale niekoniecznie tytułu. Rotujcie rolę między inżynierami, dajcie osobie na rotacji spisaną listę kontrolną i zadbajcie, by ktoś odpowiadał za każdy z siedmiu kroków.

Co powinna zawierać lista kontrolna wydania? Potwierdzony zakres, zielony pipeline na wydawanym commicie, nazwaną ścieżkę wycofania, zapisane zatwierdzenie, smoke testy po wdrożeniu, metryki porównane z poziomem bazowym, opublikowane release notes, poinformowane wsparcie i zaplanowane podsumowanie. Zmieśćcie ją na jednej stronie.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Szablon notatek wydania