Читать книгу Mikroserwisy. Wzorce z przykładami w języku Java - Chris Richardson - Страница 18

Inny problem związany z aplikacją FTGO polega na tym, że wdrażanie zmian do produkcji jest długim i bolesnym procesem. Zespół zazwyczaj wdraża aktualizacje do produkcji raz w miesiącu, zwykle późno w piątek lub w sobotę wieczorem. Mary dowiedziała się, że obecnie cechą aplikacji oprogramowania jako usługi (Software-as-a-Service, SaaS) jest ciągłe wdrażanie: wdrażanie zmian do produkcji wiele razy dziennie w trakcie godzin pracy. Jak się okazuje, od 2011 r. Amazon.com wdraża zmiany do produkcji średnio co 11,6 sekundy, nie wpływając na użytkownika! Dla programistów FTGO aktualizacja produkcji więcej niż raz w miesiącu wydaje się odległym marzeniem. A przyjęcie ciągłego wdrażania wydaje się prawie niemożliwe.

FTGO częściowo przyjęło metodykę zwinnego zarządzania. Zespół inżynierów jest podzielony na małe zespoły i wykorzystuje dwutygodniowe sprinty. Niestety droga od kompletnego kodu do uruchomienia w produkcji jest długa i uciążliwa. Jednym z problemów związanych z tyloma programistami wprowadzającymi zmiany do tej samej bazy kodu jest to, że często on nie jest w stanie stworzyć wydania. Gdy programiści FTGO próbowali rozwiązać ten problem za pomocą gałęzi, ich próby powodowały konieczność późniejszego długiego i bolesnego scalania. W konsekwencji, gdy zespół zakończy sprint, następuje długi okres testowania i stabilizacji kodu.

Innym powodem, dlaczego tak długo trwa wprowadzanie zmian do produkcji, jest to, że dużo czasu zajmuje testowanie. Ponieważ kod jest złożony, a wpływ danej zmiany nie jest dobrze poznany, programiści i serwer wykonujący ciągłą integrację (Continuous Integration, CI) muszą uruchamiać cały pakiet testów. Niektóre części systemu wymagają nawet ręcznego testowania. Diagnoza i naprawa przyczyny niepowodzenia testu zajmuje trochę czasu. W rezultacie cykl testowania zajmuje kilka dni.