Ciągłe dostarczanie

Pipeline ciągłego dostarczania może obejmować etap ręcznego warunkowania tuż przed wdrożeniem w środowisku produkcyjnym. Ręczne warunkowanie wymaga interwencji człowieka, a w Twojej organizacji mogą istnieć scenariusze, które wymagają ręcznego warunkowania w pipeline'ach. W niektórych przypadkach ręczne warunkowanie może budzić wątpliwości, podczas gdy w innych może być uzasadnione. Jeden uzasadniony scenariusz pozwala zespołowi biznesowemu w ostatniej chwili podjąć decyzję o wydaniu. Po każdym sprincie zespół inżynierski utrzymuje w gotowości wersję produktu nadającą się do wydania, a zespół biznesowy daje ostateczny sygnał do udostępnienia produktu wszystkim klientom lub przekrojowi społeczeństwa, a niekiedy tylko osobom mieszkającym w określonej lokalizacji geograficznej.

Architektura produktu przechodzącego przez pipeline jest kluczowym czynnikiem determinującym anatomię pipeline'u ciągłego dostarczania. Wysoce zależna architektura produktu generuje skomplikowany graficzny wzór pipeline'u, w którym różne pipeline'y mogą się zaplątać, zanim ostatecznie trafią do środowiska produkcyjnego.

Architektura produktu wpływa również na różne fazy pipeline'u i artefakty produkowane w każdej fazie. Najpierw w ramach pipeline'u są kompilowane komponenty — najmniejsze nadające się do dystrybucji i testowania jednostki produktu. Przykładowo bibliotekę zbudowaną przez pipeline można nazwać komponentem. To jest faza komponentów.

Luźno sprzężone komponenty tworzą podsystemy — najmniejsze jednostki nadające się do wdrożenia i uruchomienia. Przykładowo podsystemem jest serwer. Przykładem podsystemu jest również mikrousługa działająca w kontenerze. To jest faza podsystemów. W przeciwieństwie do komponentów podsystemy można uruchomić i przetestować.

W związku z tym można nauczyć pipeline składania systemu z luźno powiązanych podsystemów, w przypadkach gdy kompletny system powinien zostać wydany jako całość. To jest faza systemu.

To podejście na zasadzie „wszystko albo nic” powoduje, że najszybszy podsystem pracuje z prędkością najwolniejszego. „Łańcuch jest tak silny, jak jego najsłabsze ogniwo” — tym frazesem ostrzegamy zespoły, które padają ofiarą tego wzorca architektonicznego.

Po zatwierdzeniu poskładany system jest przekazywany do produkcji bez żadnych dalszych modyfikacji i tym samym wchodzi w końcową fazę zwaną fazą produkcji.

Należy zwrócić uwagę, że te fazy mają charakter bardziej logiczny niż fizyczny, a zdefiniowano je jedynie w celu rozbicia dużego problemu na wiele mniejszych problemów podrzędnych. W zależności od architektury i wymagań faz może być mniej lub więcej.

Z punktu widzenia naszych klientów szybkość bez jakości jest bezużyteczna. Ciągłe testowanie to technika, w której automatyczne testy są zintegrowane z pipeline'em dostarczania oprogramowania i sprawdzają poprawność każdej zmiany przechodzącej przez pipeline. Testy są wykonywane w każdej fazie pipeline'u w celu weryfikacji artefaktów wyprodukowanych w tej fazie. Testy jednostkowe i statyczna analiza kodu pozwalają sprawdzić poprawność komponentów w fazie komponentów pipeline'u. Testy funkcjonalne, wydajności i zabezpieczeń pozwalają zweryfikować podsystemy w fazie podsystemów. Testy integracyjne, wydajności i zabezpieczeń pozwalają sprawdzić poprawność systemów w fazie systemu. Wreszcie testy smoke pozwalają zweryfikować produkt w fazie produkcji.