Читать книгу Wzorce Cloud Native - Cornelia Davies - Страница 16

Kolejną krytycznie ważną rzeczą jest możliwość częstego wydawania nowych wersji kodu. Napędzane przez znaczącą konkurencję i zawsze rosnące oczekiwania klientów aktualizacje aplikacji są udostępniane klientom kilka razy w miesiącu, wiele razy w tygodniu, a w pewnych sytuacjach nawet kilka razy dziennie. Ekscytacja klientów jest niewątpliwie ważna, ale być może największą motywacją tych ciągłych wydań jest zmniejszenie ryzyka.

Od momentu, gdy mamy pomysł na funkcjonalność, podejmujemy na pewnym poziomie ryzyko. Czy to dobry pomysł? Czy klienci będą w stanie go używać? Czy można to zaimplementować w wydajniejszy sposób? Mimo największych starań przewidzenia możliwych rezultatów rzeczywistość jest często różna od naszych oczekiwań. Najlepszym sposobem na uzyskanie odpowiedzi na ważne pytania, takie jak wspomniane, jest wydanie wczesnej wersji funkcjonalności i zebranie zwrotnych informacji. Używając ich, możemy dokonać poprawek lub nawet całkowicie zmienić kierunek naszych działań. Częste wydania oprogramowania skracają pętlę informacji zwrotnych i zmniejszają ryzyko.

Monolityczne systemy oprogramowania, które dominowały przez kilka ostatnich dekad, nie mogą być wydawane wystarczająco często. Zbyt wiele ściśle powiązanych ze sobą podsystemów, zbudowanych i testowanych przez niezależne zespoły, musiało być testowanych jako całość, nim często delikatny proces paczkowania mógł zostać rozpoczęty. Jeśli defekt był znaleziony późno, w fazie testów integracyjnych, długi i pracochłonny proces rozpoczynał się na nowo. Konieczne są nowe architektury oprogramowania, by osiągnąć wymaganą zwinność w wydawaniu oprogramowania produkcyjnego.