CD czyli Continuous Delivery 

Jakiś czas temu miałem przyjemność na łamach niniejszego bloga napisać tekst dotyczący Continuous Integration. Już wtedy wspominałem, że prócz CI istnieją jeszcze inne podejścia powiązane z ideą ciągłości, a więc CD (Continuous Delivery) oraz… CD (Continuous Deployment). Dziś nadszedł czas na drugi element całości… Panie i Panowie oto Continuous Delivery.

Continuous znaczy ciągły

Zasada ciągłości, leży u podwalin wszystkich wspomnianych idei. Continous Delivery to nic innego jak dostarczanie oprogramowanie w bardzo krótkich cyklach. Nie musi być ono nawet tworzone przez zespoły scrumowe, bo do wykorzystania idei Continuous Delivery wystarczy po prostu iteracyjne wytwarzanie oprogramowania.

Czym są owe iteracje? To powtarzalne czynności, mające na celu zapewnienie odpowiedniej jakości wytwarzanego oprogramowania. Każda jego część musi przejść przez zdefiniowane etapy, podczas których następuje weryfikacja różnymi dostępnymi metodami. W tym także, jeśli zachodzi taka potrzeba, przy pomocy testów manualnych.

Mówiąc o CD nie można nie wspomnieć, że ważnym elementem tego podejścia jest zapewnienie wiarygodności, pełnej transparentności oraz potencjalnej wdrażalności dostarczanego fragmentu oprogramowania.

Tylko regularne tworzenie kompletnych i poprawnych przyrostów może pokazać, że idea Continuous Delivery jest faktycznie obecna w naszej organizacji. Bez spełnienia powyższych warunków nie będziemy w stanie wziąć odpowiedzialności za jakość dostarczanego w cyklach oprogramowania.

Korzyści Continuous Delivery

Implementując zasadę Continuous Delivery spodziewamy się osiągnąć określone korzyści. Mówi się, że dzięki ciągłemu wdrażaniu jesteśmy w stanie zredukować koszty naszego projektu jak również czas trwania dewelopmentu danej funkcjonalności. Inaczej mówiąc – ograniczamy ryzyko. I trudno się z tym stwierdzeniem nie zgodzić.

Mówiąc o „czasie trwania” mamy na myśli skrócenie czasu potrzebnego na wdrożenie na środowisko produkcyjne, czyli time-to-market. Poprzez redukcję ryzyka rozumiemy częstszą informację zwrotną od klienta, pozwalającą na wytworzenie produktu ściśle związanego z jego potrzebami i brak obaw co do technicznej możliwości implementacji przygotowanego produktu, czyli zaufanie.

Czy Continuous Delivery ma wady? Zaliczyłbym do nich przede wszystkich nastawienie klienta, który może chcieć gotowy, ukończony produkt. Jest to bolączka dobrze znana z wszystkich metodyk agile. Problematyczne bywają też aspekty techniczne. Może nam przeszkadzać brak narzędzi umożliwiających automatyczne testowanie zmian i odpowiednich, właściwie skonfigurowanych środowisk. Jak to zwykle bywa, bez odpowiedniego przygotowania nie osiągniemy efektów płynących z Continuous Delivery.

Z tym pierwszym możemy spróbować poradzić sobie, wypracowując z klientem właściwe podejścia (Agile Mindset). Wyzwania należące do tej drugiej kategorii wymagać będą od nas konkretnych działań nastawionych na zmianę naszego środowiska deweloperskiego.

„si-aj” kontra „si-di”

Continuous Integration, o którym pisałem wcześniej i temat dzisiejszego wpisu ściśle się ze sobą łączą.

Nie ma Continuous Delivery bez Continuous Integration.

Oba podejścia bardzo mocno się przenikają. Niektórzy nawet są w stanie zaryzykować tezę, że są one sztucznie rozdzielone, że można by potraktować je jako ten sam proces. Tylko przy skutecznym CI będziemy mogli szybko tworzyć, weryfikować i implementować na poszczególnych środowiskach zmiany w ramach CD.

Jestem jednak zwolennikiem teorii mówiącej o rozdzieleniu obu procesów. Przemyślane Continuous Delivery wcale nie musi wprost przekładać się na Continuous Integration. Możemy mieć naprawdę świetne delivery, zespół składający się z najlepszej klasy specjalistów, ale bez naprawdę dobrze przemyślanego Continuous Integration nie uda nam się osiągnąć zakładanych celów. Aby do tego nie dopuścić musimy wypracować (w przypadku obu podejść) zestaw najlepszych praktyk a następnie dbać o to, aby weryfikować ich poprawność w czasie.

Scrum, a Continuous Delivery

Wróćmy na chwilę do początków zwinnego podejścia czyli do Agile Manifesto:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” – Agile Manifesto

Oznacza to, że najwyższym priorytetem powinno być zadowolenie klienta poprzez wczesne i ciągłe wdrażanie oprogramowania, którego potrzebuje. Czy nie jest to właśnie idea adresowana przez podejście zwane „ciągłym dostarczaniem”?

Analizując Continuous Delivery trudno nie oprzeć się właśnie takiemu złudzeniu. Potencjalnie wdrażalny inkrement, będący efektem prac zespołu scrumowego w pełni odpowiada na potrzeby podejścia CD.

Już samo „potencjalnie wdrażalny” sugeruje konieczność spełnienia wymogu wiarygodności i gotowości do wdrożenia na środowisko produkcyjne w dowolnej chwili. Dodatkowo, biorąc pod uwagę cykliczne podejście do wytwarzania oprogramowania, zwane w Scrum Sprintami, otrzymujemy podręcznikowy wręcz przykład Continuous Delivery.

A tak jak niektórzy utożsamiają ze sobą CD i CI, tak samo Continous Delivery bywa przyrównywane do zwinnego wytwarzania oprogramowania.