Wydania i zarządzanie wydaniami są istotną częścią naszej pracy. Wydanie właściwego produktu klientom sprawi, że będą zadowoleni. Sprawne przeprowadzenie wydania sprawi, że my, osoby zaangażowane w wydanie, również będziemy zadowoleni.
Jak możemy osiągnąć sprawne wydanie?
Biorąc udział w dużej liczbie takich procesów, mogę powiedzieć, że istnieje kilka kluczowych kwestii, które mogą pomóc w osiągnięciu skutecznego zarządzania wydaniami.
Opowiem, jakie one są.
Skuteczne wydanie zaczyna się w trakcie prac programistycznych.
Identyfikowanie przypadków testowych
Dobre zarządzanie wydaniami zaczyna się na długo przed dniem wydania, już w momencie, gdy funkcja przeznaczona do wydania znajduje się w fazie programowania. W tym czasie funkcja musi uzyskać akceptację zespołu ds. zapewnienia jakości. Oznacza to, że musimy przetestować wszystkie możliwe scenariusze, które przychodzą nam do głowy i mają sens w przypadku danej funkcji, aby potwierdzić, że działa ona zgodnie z wymaganiami. Część z tych scenariuszy zostanie przetestowana za pomocą testów automatycznych, natomiast w przypadku niektórych utworzenie automatyzacji jest zbyt trudne lub nieopłacalne.
Określając rodzaj testów, które musimy przeprowadzić dla danej funkcji, powinniśmy wziąć pod uwagę następujące kwestie: gdy funkcja po raz pierwszy trafia na środowisko produkcyjne, musimy ją w pełni przetestować. Musimy upewnić się, że klienci nie znajdą żadnych krytycznych problemów. Musimy zweryfikować wymagania. Musimy także zapewnić prawidłową wydajność funkcji.
Opóźnienia i problemy podczas testowania mogą poważnie wpłynąć na harmonogram przygotowań do wydań oprogramowania. Włączenie skutecznych praktyk zarządzania wydaniami pomoże zapewnić niezawodność i przewidywalność testowania oraz wdrażania.
Jednak gdy funkcja zostanie już uruchomiona, nie musimy jej tak dokładnie testować przy każdym kolejnym wydaniu tej samej bazy kodu, chyba że wymagane są dla niej aktualizacje. Zachowanie funkcji zmieni się tylko wtedy, gdy zmodyfikowany zostanie kod leżący u jej podstaw albo nastąpi zewnętrzna zmiana dotycząca którejś z wykorzystywanych przez nią zależności. W pozostałych przypadkach wystarczą testy poprawności funkcji, które oczywiście powinny obejmować najważniejsze przypadki testowe.
Mając to na uwadze, gdy funkcja jest w fazie programowania, upewnij się, że oceniasz: ile przypadków testowych musisz przetestować; ile czasu masz na testowanie; które przypadki testowe są krytyczne; które przypadki testowe będziesz uruchamiać przy każdym wydaniu.
W ten sposób możesz określić, które przypadki testowe zautomatyzujesz. Skup się na tym, aby automatyzacja obejmowała co najmniej krytyczną funkcjonalność. W przypadku pozostałych testów powinieneś utworzyć pisemne przypadki testowe w systemie śledzenia projektu (np. Jira) albo w używanym przez Ciebie narzędziu do zarządzania testami. Dzięki temu nie zostaną zgubione ani zapomniane i będzie można je uruchomić za każdym razem, gdy będzie tego wymagało wydanie.
Have an account? Log In
Uruchamianie testów w CI
Gdy masz już testy automatyczne, powinieneś zacząć okresowo uruchamiać je za pośrednictwem CI na środowiskach deweloperskich. Ponieważ przed wydaniem opracowywane są kolejne funkcje, warto upewnić się, że funkcja, którą chcesz wydać, nadal działa prawidłowo, szczególnie jeśli została już przez Ciebie zaakceptowana podczas sprintu. Uruchamianie testów interesującej Cię funkcji, na przykład codziennie, zapewni szybką informację zwrotną o poprawkach, które należy wprowadzić w funkcji z powodu błędów spowodowanych innymi zmianami w systemie.
Wczesne wykrycie potencjalnych błędów w funkcji przeznaczonej do wydania zapewni dużo czasu na wprowadzenie poprawek i ponowne przetestowanie funkcji, bez stresu związanego z wykonywaniem tych czynności w ograniczonym czasie dostępnego podczas fazy wydania. Im większą część wymagań obejmują testy automatyczne, tym większe prawdopodobieństwo, że w fazie wydania znajdziesz tylko niewielką liczbę błędów.
Środowisko przedprodukcyjne jest ważne i powinno mieć wbudowany bufor czasowy.
Ramy czasowe
Faza wydania zwykle obejmuje okres przeznaczony na testowanie w przedprodukcyjnym środowisku integracyjnym, niezależnie od dnia lub okresu wydania produkcyjnego. Jako tester zaangażowany w wydanie zawsze upewniam się, że proszę o odpowiednie przedziały czasowe na wydanie, tak aby faza przedprodukcyjna umożliwiała mi właściwe przetestowanie funkcji przeznaczonych do wydania.
Zawsze uwzględniam również bufor czasowy, ponieważ spodziewam się, że w procesie zarządzania wydaniami pojawią się nieprzewidziane problemy, niezależnie od tego, czy będą to błędy w funkcjach przeznaczonych do wydania, czy czynniki zewnętrzne. Wspominając tylko o jednym z tych czynników, środowiska przedprodukcyjne są środowiskami testowymi i mogą nie być tak niezawodne, jak powinny. Wielokrotnie działają bardzo wolno albo stają się na jakiś czas niedostępne, dokładnie wtedy, gdy odbywa się testowanie wydania.
Posiadanie dodatkowego czasu rezerwowego jest zawsze dobrym pomysłem i nawet jeśli nie wykorzystasz tego dodatkowego czasu, nic się nie stanie. Możesz zatwierdzić wersję przed upływem przydzielonego czasu na testy, ponieważ pozostały czas możesz przeznaczyć na pracę nad czymś innym. Gorzej jest nie mieć czasu rezerwowego, gdy jest potrzebny, ponieważ w takim przypadku będziesz musiał w jakiś sposób zmieścić wszystkie wymagane testy w krótszym czasie. Może to doprowadzić do pominięcia niektórych przypadków testowych, co z kolei może skutkować tym, że pewne błędy zostaną wykryte bezpośrednio na produkcji.
Zakres
Kolejnym ważnym aspektem wydania przedprodukcyjnego, z mojej perspektywy, jest wyznaczenie koordynatora zarządzania wydaniem. Dla mnie oznacza to osobę, która zajmuje się określonymi aspektami, z których pierwszym jest sprawdzenie zakresu wydania. Przed rozpoczęciem testowania dowolnego wydania tester musi wiedzieć, co należy przetestować. Sprowadza się to do zakresu wydania.
Osoby z zespołu produktowego, czyli PO lub BA, oczekują, że określone funkcje trafią do wydania, a ustalenie to następuje na początku prac programistycznych. Jednak kod, który trafia do wydania, nie zawsze obejmuje dokładnie taki zakres, jakiego oczekuje zespół produktowy. Czasami ktoś zapomni wypchnąć kod do gałęzi, z której tworzony jest kompilat wydania. Albo, co gorsza, może wypchnąć do tej gałęzi kod, którego nie powinno tam być. Mogą to być funkcje, które nie są jeszcze ukończone i nie uzyskały akceptacji QA, albo funkcje, które nie wchodzą w obecny zakres.
Aby mieć pewność, że zakres zostanie zrealizowany, koordynator wydania powinien porównać oczekiwany zakres z zakresem rzeczywistym. Oczekiwany zakres powinien pochodzić od osób odpowiedzialnych za produkt i być jasno określony w pewnego rodzaju dokumentach (być może także w planie zapewniania jakości). Możesz na przykład mieć dokumenty planistyczne pokazujące kamienie milowe projektu oraz to, co obejmuje każdy z nich.
W przypadku rzeczywistego zakresu należy wyodrębnić dziennik zmian z używanego w projekcie systemu kontroli wersji (VCS, np. Git). Dziennik zmian będzie odzwierciedlał wszystkie zatwierdzenia wykonane podczas fazy programowania w gałęzi, z której zostanie utworzony kompilat wydania. Miejmy nadzieję, że jeśli pracujesz w uporządkowany sposób, każde zatwierdzenie będzie zawierało opis wskazujący element Jira, do którego odnosi się kod. Dzięki temu możesz zobaczyć, które elementy Jira mają odpowiadający im kod trafiający do kompilatu wydania, a które z nich nie powinny były zostać uwzględnione w tym kompilacie. Oczywiście, jeśli okaże się, że te zatwierdzenia dotyczą niezbędnych poprawek błędów, jest to całkowicie w porządku. Nie chcesz natomiast, aby te zatwierdzenia oznaczały niedokończone prace nad funkcjami lub prace związane z funkcjami, które nie powinny trafić na produkcję w ramach bieżącego wydania.
W miarę poznawania zaawansowanych technik zarządzania wydaniami przekonasz się, że zintegrowanie procesów z rozwiązaniami do zarządzania testami zaprojektowanymi dla Jira może zapewnić bardziej spójny i wydajny przepływ pracy.
Za każdym razem, gdy zostanie wykryta rozbieżność między oczekiwanym a rzeczywistym zakresem, koordynator zarządzania wydaniem powinien skonsultować się z zespołem produktowym i kierownikami zespołów programistycznych, aby ustalić najlepsze podejście. Jeśli okaże się, że zatwierdzenia nieobjęte zakresem dotyczą niedokończonych prac nad funkcjami, najlepiej je usunąć. Dzieje się tak dlatego, że jesteś już w fazie wydania przedprodukcyjnego i nie chcesz ryzykować dopuszczenia do sytuacji, w której pozostały kod zostanie napisany i przetestowany w pośpiechu tylko po to, aby trafić do wydania. Jest to ryzykowne, ponieważ taki pośpiech może doprowadzić do pominięcia i niewykonania przypadków testowych oraz do przedostania się krytycznych błędów na produkcję. W takiej sytuacji najlepiej pozwolić na właściwe ukończenie pozostałych prac nad tymi funkcjami w ramach przyszłego wydania.
Testowanie
Gdy zakres jest już jasny, należy rozpocząć fazę testowania. W fazie testów przedprodukcyjnych trzeba ponownie zweryfikować całą wydawaną funkcję. Wyobraź sobie, że widzisz ją po raz pierwszy, i przetestuj każdy scenariusz, który sprawdzałeś w fazie programowania. Uruchom napisane wcześniej testy automatyczne, ale w środowisku przedprodukcyjnym, i nie zapomnij o scenariuszach nieautomatycznych. Wykonaj pełne testy regresji tej funkcji, ponieważ gdy znajdujesz się już w tej fazie zarządzania wydaniem i w środowisku przedprodukcyjnym, prawdopodobnie są inne zespoły, które będą musiały wydać swoje zmiany w tym samym czasie co Ty. Jest to w zasadzie pierwszy moment, gdy wszystkie zależności spotykają się w tym samym środowisku wraz z kodem gotowym do wdrożenia na produkcję. Teoretycznie jest to również konfiguracja, która od momentu wydania będzie działać na produkcji.
Chyba że podczas testowania zostaną wykryte problemy i konieczne będzie wprowadzenie poprawek. Jeśli tak się stanie, musisz rozważyć, co należy przetestować ponownie. Niezależnie od tego, czy poprawka znajduje się w Twoim kodzie, czy w kodzie zewnętrznej zależności, jeśli zmiany w jakikolwiek sposób wpływają na Twoją funkcję, musisz rozważyć kolejną rundę testów. Upewnij się, że ponownie przetestujesz co najmniej krytyczne działanie funkcji.
Może się to wydawać nudne, zwłaszcza jeśli w tej fazie zostanie wprowadzonych wiele poprawek. Nie możesz jednak dokładnie przewidzieć wpływu, jaki poprawki mogą mieć na różne części funkcji.
Niewielkie zmiany mogą powodować ogromne skutki uboczne, dlatego lepiej się nudzić, ale mieć pewność, że krytyczne działanie nadal funkcjonuje prawidłowo, niż żałować, że nie wykonano wystarczającej liczby testów.
I oczywiście, jeśli jakikolwiek błąd znaleziony podczas tej fazy testów jest błędem nieistotnym, nie zawracaj sobie głowy jego naprawianiem na tym etapie. Ponownie: nie chcesz w pośpiechu implementować ani testować czegoś, co poza tym działa prawidłowo, aby nie stwarzać ryzyka jego uszkodzenia.
Podczas wdrażania kluczowe znaczenie mają komunikacja i testowanie.
Po zatwierdzeniu funkcji w środowisku przedprodukcyjnym jest ona gotowa do wdrożenia na środowisko produkcyjne.
Komunikacja
Jeśli chodzi o wdrożenie na środowisko produkcyjne, koordynator zarządzania wdrożeniem ma do wykonania kilka zadań. Przede wszystkim data i godzina wdrożenia powinny zostać odpowiednio ustalone z wyprzedzeniem i przekazane wszystkim zaangażowanym stronom. Uważam, że umieszczenie daty i godziny wdrożenia jako spotkania w kalendarzach uczestników jest bardzo pomocne w zarządzaniu wdrożeniem, ponieważ pozwala uczestnikom zaplanować dzień — jest to zadanie, które może wykonać koordynator.
W dniu wdrożenia koordynator powinien przypomnieć wszystkim zaangażowanym o harmonogramie wdrożenia. W idealnej sytuacji komunikacja powinna odbywać się za pośrednictwem kanału używanego przez wszystkich, na przykład Slacka. Utworzenie dedykowanego kanału Slack, na którym przekazywane są wszystkie ważne informacje, zapewnia wszystkim zaangażowanym takie samo rozumienie tego, jaki etap wdrożenia został wykonany i kiedy, jaki jest zakres, jakie problemy wykryto oraz kto może pomóc w ich rozwiązaniu. Taka komunikacja zapewnia, że osoba, która musi znać określone aspekty wdrożenia, zobaczy te informacje, w przeciwieństwie do komunikacji ustnej (w przypadku której tej osoby może nie być obecnej, a osoba przekazująca informacje może tego nie zauważyć).
Koordynator zarządzania wdrożeniem powinien śledzić i ogłaszać na tym kanale najważniejsze etapy wdrożenia, takie jak rozpoczęcie wdrożenia czy jego zatwierdzenie. Ponadto każda strona zaangażowana we wdrożenie powinna za pośrednictwem tego kanału informować, że wykonuje przydzielone jej kroki, aby wszyscy pozostali znali stan i postęp wdrożenia. Jeśli na którymkolwiek etapie wdrożenia zabraknie potrzebnej osoby, koordynator wdrożenia powinien skontaktować się z odpowiednimi osobami, aby wszystko przebiegało sprawnie.
More Articles
Testowanie
Podczas wdrożenia na środowisko produkcyjne testowanie nowej funkcji powinno zostać ponownie przeprowadzone w całości. Wynika to z faktu, że chociaż funkcja została zatwierdzona w innych środowiskach testowych, środowiska te nie są w 100% identyczne ze środowiskiem produkcyjnym pod względem konfiguracji i zasobów.
Aby zapobiec nieprzewidzianemu nieprawidłowemu działaniu wdrażanej funkcji, należy uruchomić wszystkie dostępne testy automatyczne, a także nieautomatyczne elementy, dla których napisano przypadki testowe. Nigdy nie zatwierdzaj wdrożenia na środowisko produkcyjne bez przetestowania funkcji.
Samo założenie, że funkcja działa na środowisku produkcyjnym, nie oznacza, że rzeczywiście tak jest.
Upewnij się, że tak jest — przetestuj ją.
Po wdrożeniu
Wdrożenie zostało zakończone. Jednak upewnienie się, że funkcja działa prawidłowo, wymaga więcej pracy niż samo przetestowanie jej w fazie wdrożenia.
Po zakończeniu tego etapu upewnij się, że testy automatyczne są uruchamiane w ramach CI dla środowiska produkcyjnego. Pozwoli to wykryć wszelkie niepożądane zachowania spowodowane zmianami zewnętrznymi, o których nie masz wiedzy.
Stale monitoruj wydajność funkcji, aby upewnić się, że obciążenie środowiska produkcyjnego i sposób korzystania z niego przez klientów nie powodują pogorszenia wydajności. Ponadto obserwuj wszelkie zgłoszenia problemów napływające od klientów. Mogą one wskazywać obszary, które nie działają prawidłowo, dzięki czemu możesz szybko zaplanować przyszłą aktualizację, jeśli okaże się potrzebna.
Jeśli wdrożenie nie przebiegło zgodnie z oczekiwaniami, zorganizuj spotkanie retrospektywne po wdrożeniu. Możesz na nim omówić wszystkie problemy, które wystąpiły w ramach procesu zarządzania wdrożeniem, oraz przydzielić odpowiednim osobom zadania do wykonania, aby każde przyszłe wdrożenie przebiegało sprawnie i pomyślnie.
