W kontekście metodyki Scrum, standardowym oczekiwaniem jest, że po zakończeniu sprintu następuje publikacja nowej wersji oprogramowania. Innymi słowy, zaraz po pomyślnej prezentacji demo dla klienta.
Zastanawiałem się jednak, czy takie automatyczne podejście jest zawsze właściwe. Szczególnie gdy weźmie się pod uwagę szereg działań, które często muszą zostać wykonane przed lub równolegle z wdrożeniem.
- Ukończenie wszystkich zadań (tzw. historyjek) zaplanowanych na dany sprint. Choć niektóre z nich mogą być gotowe wcześniej, to często ich finalizacja przypada na sam koniec sprintu, a czasem nawet po prezentacji demo.
- Przeprowadzenie wszystkich zaplanowanych testów, aby upewnić się, że kod jest gotowy do wdrożenia na środowisko produkcyjne.
- Usunięcie wykrytych błędów i ich naprawa przed publikacją.
- Uaktualnienie potoku wdrożeniowego do najnowszej wersji i zweryfikowanie jego niezawodności.
- Uruchomienie potoku we wszystkich docelowych środowiskach w celu uaktualnienia ich kodu i danych.
- Przygotowanie informacji o wydaniu i poinformowanie klienta o zakresie zmian i ich potencjalnym wpływie.
- W razie potrzeby synchronizacja z innymi zespołami pracującymi w Scrum, aby zapewnić jednoczesne wdrożenie powiązanych zmian. Chodzi o to, by niczego nie brakowało, a całość działała zgodnie z założeniami.
- Realizacja wszystkich ceremonii Scrum, zarówno tych bieżącego sprintu, jak i tych dotyczących kolejnego (np. sesje uszczegóławiania zadań).
Weźmy pod uwagę, że sprint trwa dwa tygodnie.
Czynności związane z samym procesem wydania wymagają czasu i zaangażowania zespołu. Nie można ich wykonać zbyt szybko, gdyż bezpośrednio po ostatnim dniu sprintu następuje pierwszy dzień kolejnego i cykl zaczyna się od nowa.
Czy w takiej sytuacji automatyczne wdrożenie po każdym sprincie nadal wydaje się tak oczywiste?
Proces przygotowania do wdrożenia
W sytuacji idealnej, gdy wszystkie procesy są w pełni zautomatyzowane, można by teoretycznie wdrożyć najnowszą wersję oprogramowania na produkcję na koniec każdego sprintu. Jednak w mojej praktyce rzadko spotykam zespoły Scrum, które osiągnęły taki poziom dojrzałości.
Być może niektóre mniejsze firmy tak działają i szczerze im zazdroszczę. W większości korporacji zespoły Scrum nie osiągają tego poziomu. Procesy wdrożenia są zazwyczaj czasochłonne, a ich realizacja rozciąga się na kolejny sprint, wpływając na jego zawartość i mierniki. Wdrożenie jest stresującym wydarzeniem, którego nikt w zespole nie wyczekuje.
Zacząłem poszukiwać lepszego sposobu na radzenie sobie z wydaniami.
Rozwiązaniem okazało się przekształcenie co drugiego sprintu w sprint wydaniowy. Na czym to polega?
Oddzielna gałąź kodu dla nowej wersji
Kluczowe jest tutaj zarządzanie oddzielnymi gałęziami w repozytorium GIT. Istnieje wiele podejść do tego tematu, które mogą prowadzić do sukcesu. W tym tekście skupię się na uproszczonym modelu, aby łatwiej zobrazować jego działanie i korzyści.
Aby minimalnie zakłócić prace rozwojowe, zawartość przeznaczoną na kolejne wdrożenie warto przenieść do oddzielnej gałęzi. Nazwijmy ją Gałęzią Wydania. Takie podejście pozwala na rozwiązanie następujących kwestii:
- Zespół programistów może nieprzerwanie pracować nad nowymi zadaniami i integrować je z główną gałęzią.
- Nie istnieje ryzyko, że nieprzewidziane zmiany w kodzie wprowadzone przez zespół Scrum wpłyną na zawartość wydania.
- Testy mogą być wykonywane w izolowanym środowisku. Tutaj wprowadzane są tylko zmiany niezbędne do rozwiązania ewentualnych problemów testowych.
- Potok wdrożeniowy publikuje tylko zawartość z Gałęzi Wydania, co zapewnia przejrzystość i kontrolę nad tym, co zostanie wdrożone. Eliminujemy ryzyko, że przypadkowa zmiana w repozytorium GIT popsuje już przetestowany kod.
W ten sposób możemy „odłożyć na bok” zawartość przeznaczoną do wdrożenia i pozwolić jej dojrzeć do stabilnej, gotowej do publikacji formy.
Planowanie cyklicznych wydań
Zrezygnowałem z pomysłu wdrożeń po każdym sprincie. Stało się jasne, że to nie ma szans zadziałać. A przynajmniej nie bez znaczących negatywnych konsekwencji, takich jak:
- zakłócenia w rozwoju treści kolejnego sprintu,
- problemy ze stabilizacją zawartości wydania,
- niemożność wykonania wszystkich niezbędnych testów, itd.
Celem stało się wdrożenie na koniec co drugiego sprintu. Co to oznacza w praktyce?
- Wdrożenie zawsze obejmie zadania z dwóch poprzednich sprintów. Ponieważ wdrażanie odbywa się w trakcie trwającego sprintu, jego zawartość nie jest jeszcze brana pod uwagę.
- Mamy cały jeden sprint na wykonanie testów i usunięcie błędów.
- Właściciel wydania ma czas na zebranie informacji o wydaniu (przypadki testowe, opis zmian, itd.) w trakcie sprintu niewydaniowego. Może działać samodzielnie, a reszta zespołu skupia się na nowych zadaniach.
- W przypadku wykrycia błędu, właściciel wydania może szybko skontaktować się z konkretnym programistą w celu rozwiązania problemu i powrotu do bieżących prac nad sprintem. Dlatego w planowaniu zawsze należy uwzględnić pewien procent czasu na usuwanie błędów. W praktyce szybko można określić, jaka to wartość.
Oczywiście użytkownicy nie otrzymają najnowszych zmian z każdego sprintu w kolejnej wersji. Jednak z czasem to przestanie mieć znaczenie. W zamian, regularnie co drugi sprint będą otrzymywać zestaw zmian z dwóch poprzednich sprintów.
Taka strategia to dobry kompromis między szybkim dostarczaniem nowej wartości a utrzymaniem płynnego rytmu prac w Scrum.
Wdrożenie na produkcję
Gdy testowanie, naprawianie błędów i potok wdrożeniowy są gotowe, samo wdrożenie na produkcję staje się prostym procesem.
Ponieważ wdrożenie odbywa się z oddzielnej gałęzi, cała operacja jest zazwyczaj niezauważalna. W idealnej sytuacji nikt poza zespołem deweloperskim nie musi o niej wiedzieć. To jest najlepszy dowód dobrze zrealizowanego wdrożenia.
Warunkiem koniecznym jest posiadanie solidnego, zautomatyzowanego potoku DevOps. Służy on nie tylko do wdrożeń na produkcję, ale także we wszystkich innych środowiskach: developerskich, testowych, QA, wydajnościowych, itd. Wdrożenie do każdego środowiska powinno dać się wykonać jednym kliknięciem.
Proces wdrożenia nie powinien być źródłem stresu, ani koszmarem, którego wszyscy się boją. Wręcz przeciwnie, im mniej osób go zauważy, tym lepiej, co świadczy o udanym wydaniu.
Scalenie gałęzi wydania z gałęzią deweloperską
Gałąź wydania zawiera teraz specjalną zawartość, której nie ma w zwykłej gałęzi rozwojowej. Dotyczy to wszystkich poprawek z okresu testowego. Musimy je włączyć z powrotem do gałęzi deweloperskiej, by zmiany zostały zachowane na kolejne wydania.
W tym momencie najnowsza gałąź wydania stanowi kod awaryjny, gotowy do ponownego wdrożenia. Jeśli po wdrożeniu produkcyjnym pojawi się pilny problem, można wykorzystać tę gałąź do jego naprawy. Wciąż jest to dokładna kopia działającego kodu, bez nowych, nieprzetestowanych zmian.
Po rozpoczęciu nowego cyklu testowego, poprzednia gałąź wydania może zostać usunięta i zastąpiona nową. Tworzymy ją jako kopię bieżącej gałęzi rozwojowej.
Ustalenie regularnego harmonogramu wydań
I gotowe 😀 — mamy solidny proces zarządzania wdrożeniami. Potrzebne jest tylko zobowiązanie do regularności. W tym przypadku co drugi sprint.
Utrzymując regularny rytm wydań, ułatwiamy ich realizację. Dlaczego?
- Ponieważ wydania nie są od siebie bardzo odległe w czasie, na produkcję wprowadzana jest niewielka ilość nowych zmian. Mały przyrost zmian jest z założenia stabilny.
- Mniejsza ilość zmian przekłada się na mniejszy nakład pracy związany z testowaniem i przygotowaniem przypadków testowych. Zmniejsza się ilość komunikacji i uzgodnień z interesariuszami. Wszyscy zgadzają się, że od ostatniego wydania nie minęło dużo czasu, dlatego waga tego działania jest mniejsza.
- Zespół przyzwyczaja się do tego cyklu pracy. Z czasem staje się on naturalną częścią ich codzienności.
- Dodatkowym efektem jest regularne odświeżanie danych w środowiskach developerskich i testowych. To jest niezbędne dla każdego nowego cyklu testowego. Działanie to przestaje być dodatkowym zadaniem, a staje się częścią rutyny. Ta zmiana perspektywy ma ogromny wpływ na atmosferę w zespole. Trudno w to uwierzyć, dopóki się tego nie doświadczy.
Podsumowanie
Tym artykułem kończę serię wpisów o cyklu życia w Scrum. Chciałem także podzielić się rozwiązaniem, które sprawdziło się w praktyce.
Często zespoły rozpoczynające pracę w Scrum robią wiele rzeczy źle. Potem z czasem ewoluują i zaczynają pracować w inny sposób. Mam nadzieję, że ta seria pomoże niektórym z nich przyspieszyć ten proces.
Prezentowane podejście do wydań nie jest jedynym możliwym i nie jest wolne od problemów. Te zawsze będą istniały i zespoły muszą się z nimi mierzyć. Należy usprawniać to, co możliwe, a odpuścić to, co nie ma sensu.
Jednak, z moich doświadczeń wynika, że takie proste podejście udowadnia, że zmiana jest możliwa. Z chaotycznych i nieprzewidywalnych sprintów można przejść do bardziej stabilnej i regularnej dostawy, na której da się polegać. Nie potrzeba do tego zaawansowanej metodologii. Wystarczą proste zasady i chęć trzymania się planu.