Zarządzanie wersjami

Zarządzanie wydaniami to dyscyplina planowania, harmonogramowania i kontrolowania sposobu, w jaki zmiany oprogramowania trafiają do produkcji. Obejmuje ona to, co zawiera wydanie, sposób jego weryfikacji, wdrożenia, monitorowania oraz cofania zmian w przypadku wystąpienia problemów. Celem jest zapewnienie, aby przejście od fazy produkcyjnej do produkcyjnej było rutynowe, a nie cykliczne.

Najbardziej spójne odkrycie w tym obszarze przeczy intuicji. Duże wydania wydają się bezpieczniejsze, ponieważ koncentrują ryzyko w jednym, starannie zarządzanym zdarzeniu, ale dowody z badań nad wydajnością dostarczania wskazują na coś innego: częste małe wydania skutkują niższym wskaźnikiem awarii i szybszym odzyskiwaniem danych. Duże wydanie zawiera wiele zmian, więc gdy coś się zepsuje, trudno jest zidentyfikować przyczynę, a wycofanie usuwa wszystko, a nie tylko jedną błędną zmianę.

Automatyzacja wdrażania to fundament, który umożliwia osiągnięcie częstotliwości. Ręczne procedury wdrażania są powolne, niespójne i podatne na błędy, a ich koszt w przeliczeniu na wydanie wywiera presję na wprowadzanie zmian w partiach, co skutkuje tworzeniem właśnie tych dużych wydań, które wiążą się z większym ryzykiem. Automatyzacja procesu, tak aby wdrożenie było powtarzalne i nie powodowało wyjątków, eliminuje motywację do akumulacji.

Oddzielenie wdrożenia od wydania to technika, która najbardziej zmienia profil ryzyka. Wdrażanie kodu do produkcji z wyłączoną funkcją za flagą, a następnie oddzielne jej włączanie, oznacza, że ​​techniczna czynność dostarczania kodu i biznesowa czynność udostępniania funkcjonalności przestają być ze sobą powiązane. Problemy we wdrożeniu są wykrywane bez wpływu na użytkowników, a funkcje mogą być udostępniane stopniowo i natychmiast wycofywane bez konieczności ponownego wdrażania.

Stopniowe ujawnianie jest naturalną konsekwencją tego podziału. Udostępnianie do niewielkiego odsetka ruchu, monitorowanie wskaźników błędów i wskaźników biznesowych oraz stopniowa ekspansja ograniczają zasięg każdego problemu do ułamka użytkowników. Jest to znacznie skuteczniejsze niż rozbudowane testy przedpremierowe w wykrywaniu klasy problemów, która pojawia się tylko w rzeczywistych warunkach produkcyjnych, przy rzeczywistym obciążeniu i danych.

Możliwość wycofania zmian musi być weryfikowana, a nie zakładana, i to właśnie tutaj wiele organizacji odkrywa problem w najgorszym momencie. Udokumentowana procedura wycofania zmian, która nigdy nie została wykonana, często zawodzi, gdy jest to konieczne, szczególnie w przypadku migracji baz danych, a zmiany schematu nie da się po prostu cofnąć. Praktykowanie wycofania zmian i projektowanie migracji z zachowaniem wstecznej kompatybilności, aby poprzednia wersja nadal działała, to właśnie ta siatka bezpieczeństwa staje się rzeczywistością.

Monitorowanie po wydaniu jest częścią procesu, a nie oddzielnym zagadnieniem. Wydanie nie jest zakończone, gdy wdrożenie zakończy się sukcesem; jest zakończone, gdy zaobserwowano, że system działa poprawnie w rzeczywistym ruchu. Zdefiniowanie z wyprzedzeniem, które wskaźniki będą monitorowane, przez jaki czas i jaki próg spowoduje wycofanie, przekształca okres po wydaniu z nieokreślonego okresu nadzoru w zdefiniowany krok z dołączoną decyzją.

Komunikacja dotycząca wydań jest ważniejsza, niż zespoły się spodziewają, szczególnie gdy zmiany są widoczne dla klientów lub wpływają na użytkowników wewnętrznych, którzy muszą być przygotowani. Zespoły wsparcia muszą wiedzieć, co się zmieniło, zanim klienci o to zapytają, a niezapowiedziane zmiany w interfejsie generują liczbę kontaktów nieproporcjonalnie dużą do ich wielkości. Krótkie, rzetelne powiadomienie docierające do osób, które będą odpowiadać na pytania, kosztuje niewiele i zapobiega przewidywalnym skutkom zakłóceń.

Ponieważ praktyka wydawania wersji jest w równym stopniu determinowana przez infrastrukturę dostarczania, co przez proces, udoskonalenie zazwyczaj wymaga inwestycji w inżynierię, a nie zmian proceduralnych. W praktyce jest to ustalane w ramach rozwój produktówmonitorowanie po uwolnieniu opiera się na pomiarach prowadzonych przez Analityka danych tak, aby można było obserwować wpływ na działalność gospodarczą, a nie tylko stan techniczny, a w organizacjach świadczących wiele usług standardy są zazwyczaj własnością całej firmy Dział IT zamiast ustalać kolejność drużyn.