W tym rozdziale
U nas zmiana przechodzi przez DEV → QA → UAT → PROD. Każde z tych środowisk ma swoją rolę. Osobno mamy portal wdrożeniowy — narzędzie do orientowania się w stanie wdrożeń.
DEV jest wspólnym środowiskiem zespołu
Do DEV łączymy zmiany kodu przygotowane przez zespół. To wspólne środowisko deweloperskie, na którym spotykają się efekty naszej pracy. Lokalny podgląd AI Engineera jest wcześniejszym miejscem pracy i demo; nie nazywam go tutaj DEV.
Ta różnica ma znaczenie: działający fragment u jednej osoby trzeba jeszcze sprawdzić razem ze zmianami pozostałych.
QA sprawdza zmianę, UAT całe wydanie
| Środowisko | Jak używamy go w naszym procesie |
|---|---|
| DEV — wspólne środowisko deweloperskie | Łączymy zmiany zespołu we wspólnej wersji aplikacji |
| QA — środowisko kontroli jakości | Zmiany przechodzą przez automatyzację testów; uruchamiają się nasze roboty testowe |
| UAT — środowisko testów akceptacyjnych | Uruchamiamy pełny zestaw testów i roboty. Product Owner odbiera całe wydanie |
| PROD — produkcja | Po przejściu wcześniejszych środowisk i odbiorze wydanie trafia do użytkowników |
Mamy automatyczne testy na każdym środowisku. Na UAT wykonujemy pełny zestaw i odbieramy całość wydania. Odbiór biznesowy przez PO pozostaje częścią tego przejścia.
Zbieramy zadania do jednego release'u
Obecnie mamy w Jira jedno zbiorcze zadanie release, czyli wydanie. Dodajemy do niego zadania, które chcemy dostarczyć w danej wersji. Wydajemy w środy lub czwartki. To nasz obecny rytm pracy, który pokazuję jako przykład.
Na UAT PO ogląda całe wydanie. To szerszy odbiór niż wcześniejsze demo jednej funkcji: kilka zmian ma razem tworzyć wersję, którą oddamy użytkownikom. Dopiero potem przechodzimy na produkcję.
Portal wdrożeniowy pokazuje stan środowisk
Portal jest osobnym elementem tego procesu. Rozdzielam zadanie release, które zbiera zakres wydania, od informacji o tym, jaka wersja rzeczywiście działa na danym środowisku.
Jeśli porządkujecie taki widok u siebie, zacznijcie od prostych pytań: co jest na DEV, co przeszło QA, co właśnie odbieracie na UAT i co działa na produkcji? Przy każdej wersji powinno dać się dotrzeć do wyniku testów i ustaleń o odbiorze. Planowane wydanie ma być odróżnione od potwierdzonego wdrożenia.
Szczegóły budowy portalu i jego integracji możemy omówić przez Pogadajmy. Tutaj pokazuję jego miejsce w pracy zespołu.
Przenieście ten przebieg na swoje wydanie
Do pobrania · Plik tekstowyKarta wydania i wiadomość do zespołuteam-wydanie-pl.mdPobierzOtwórzcie istniejące zadanie wydania, listę zmian i wyniki testów. W karcie zapiszcie waszą kolejność środowisk, wersje, wynik odbioru i to, co nadal czeka. Nazwy środowisk oraz rytm dopasujcie do własnego procesu.
Przejrzyj zadanie wydania [link] oraz dozwolone źródła [linki]. Pokaż, jakie zadania obejmuje ta wersja i co faktycznie przeszło przez kolejne środowiska. Oddziel lokalny podgląd od wspólnego środowiska zespołu. Dla każdego środowiska podaj potwierdzoną wersję, wyniki automatycznych testów oraz otwarte problemy. Wskaż wynik pełnych testów i odbioru całego wydania na środowisku akceptacyjnym. Nie wpisuj akceptacji PO bez jej potwierdzenia. Skorzystaj z dołączonej karty. Zapisz braki, sposób reakcji na problem oraz plan wycofania odpowiedni do tej zmiany. Komunikat przygotuj jako szkic. Pokaż wynik do uzgodnienia; nie zapisuj w usługach, nie wdrażaj i nie wysyłaj.
Przed produkcją ustalcie również, kto reaguje na problem i jak bezpiecznie wrócić do poprzedniego działania. Jeśli zmieniają się dane, samo cofnięcie kodu może nie wystarczyć. Po wdrożeniu sprawdźcie właściwą wersję i główną czynność pod adresem produkcyjnym. Karta zawiera pola na te ustalenia oraz komunikat do zespołu.
U nas jednym z narzędzi obserwacji jest UptimeRobot. Dostępność aplikacji i poprawne działanie jej funkcji to dwa osobne sprawdzenia.