Model ciągłego dostarczania/wdrażania
- 4 min
Wiesz już o wielu wadach "epickiego wdrożenia" jako modelu dostarczania oprogramowania, ale wiedza, co nie działa dobrze, to tylko połowa bitwy. W tej lekcji poznasz alternatywę dla tej metody monolitycznej i dowiesz się, jak może ona jeszcze bardziej zwiększyć niezawodność.
Warto również odróżnić dwa powiązane terminy, które są czasami używane zamiennie:
- Ciągłe dostarczanie: każda zmiana, która przechodzi testy automatyczne, jest gotowa do wdrożenia w środowisku produkcyjnym, ale rzeczywiste wydanie na produkcję jest uzależnione od zatwierdzenia ręcznego.
- Ciągłe wdrażanie: każda zmiana, która przechodzi testy automatyczne, jest automatycznie zwalniana do środowiska produkcyjnego bez ręcznej bramy.
Obie zależą od tych samych podstaw (częste integracje, testy automatyczne, powtarzalne potoki). Ten moduł koncentruje się na tych wspólnych podstawach.
Co to jest ciągłe dostarczanie?
Ciągłe dostarczanie to metoda, za pomocą której każda zmiana w repozytorium kodu jest gotowa do wydania w sposób szybszy, mniej stresujący, mniej ryzykowny i bardziej powtarzalny. Zamiast wprowadzać każde wdrożenie oprogramowania lub aktualizację jako wydarzenie na wielką skalę, ciągłe dostarczanie przekształca je w szybkie, rutynowe, przewidywalne doświadczenie, które odbywa się na żądanie.
Częstotliwość wdrażania: w przypadku modelu ciągłego dostarczania często odbywają się wdrożenia. Cykl może być miesięczny, tygodniowy, dzienny, a nawet godzinowy. Kluczem jest to, że wdrażasz mniejsze, bardziej ukierunkowane zmiany, częściej.
Wyzwalane przez zatwierdzenie kodu: Zamiast czekać na okno wydania zaplanowane znacznie wcześniej, potok dostarczania rozpoczyna się po zatwierdzeniu kodu. Ten kod może być oprogramowaniem, infrastrukturą lub nawet elementami takimi jak konfiguracje oprogramowania. Każda zmiana jest następnie kompilowana, testowana i gotowa do wydania. W zależności od mechanizmów kontroli organizacji, wdrożenie do środowiska produkcyjnego nadal może nastąpić później, po uzyskaniu zatwierdzenia.
Testowanie automatyczne: można używać zintegrowanego testowania automatycznego nie tylko do testowania kodu, ale także do szybkiego przekazywania opinii na temat wyników tych testów. Jest to szybka informacja zwrotna, która umożliwia szybkie iterowanie i szybkie odzyskiwanie po nieudanych testach.
Po przetestowaniu kodu możesz przetestować proces wdrażania od początku do końca w szeregu etapowych środowiskach, takich jak test, QA itd. Wdrażanie w sposób etapowy w ramach tych środowisk staje się zintegrowaną częścią doświadczenia wdrażania.
Rekordy historyczne: Nie tylko chcesz mieć historyczny rekord działań wdrażania, ale także chcesz mieć możliwość uzgodnienia środowiska produkcyjnego w danym momencie. Chcesz dowiedzieć się, które wdrożenie utworzyło bieżące środowisko produkcyjne. Dzięki tej wiedzy można śledzić takie elementy jak konfiguracje, wyniki testów i sam kod aż do pojedynczego żądania ściągnięcia, które wyzwoliło wdrożenie.
Cele wdrożenia
Teraz, gdy już wiesz, jak działa ciągłe dostarczanie, rozważ cele ciągłego dostarczania i inne rozwiązania DevOps, które pomagają osiągnąć podczas wdrażania rozwiązań programowych.
Cel 1. Zmniejszenie obciążenia związanego z wdrażaniem usług przy jednoczesnym zwiększeniu niezawodności tych usług
Zmniejszenie obciążenia wdrożeń oprogramowania i infrastruktury zwiększa codzienne doświadczenie inżynierów, którzy je uruchamiają. Wynikający z tego wzrost niezawodności zapewnia również korzyści użytkownikom końcowym, którzy widzą mniej przestojów i zakłóceń.
Cel 2. Skrócenie czasu między tym, kiedy wiadomo, że zmiana jest wymagana, a kiedy ta zmiana zostanie wdrożona w środowisku produkcyjnym
Załóżmy na przykład, że zidentyfikowano wadę kodu wpływającą na przychód i wiesz dokładnie, jak go naprawić. Dzięki dojrzałym rozwiązaniom DevOps ścieżka od zatwierdzenia do środowiska produkcyjnego jest krótka i przewidywalna. Zmiana jest kompilowana, automatycznie testowana w odpowiednich środowiskach i przygotowywana do wydania w ciągu kilku minut. Po uzyskaniu wymaganego zatwierdzenia, można go awansować do środowiska produkcyjnego, zamiast być wstrzymywane w przyszłym oknie wydania.
Cel 3. Skrócenie czasu między pomysłem a dostarczaniem oprogramowania do użytku
Ten cel jest podobny do poprzedniego, ale koncentruje się na innowacjach, a nie poprawkach. Jak długo trwa działanie nad nowym pomysłem? Dzięki temu modelowi wdrażania można zintegrować nową koncepcję z systemem produkcyjnym z pewnością, że dodatek nie zostanie przerwany ani nie utrudni bieżącego systemu. To zaufanie pozwala szybko dostarczać nowe funkcje.
Wyniki wdrożenia
Cele omówione w tej lekcji nie są tylko aspiracjami teoretycznymi, są one wymierne. Od 2014 r. zespół DevOps Research and Assessment (DORA) opublikował roczne badania stanu devops na temat wydajności dostarczania oprogramowania. W ostatnich latach ta praca została opublikowana jako Accelerate State of DevOps Report. Bieżący model DORA śledzi pięć metryk dostarczania:
- Częstotliwość wdrażania
- Zmiana czasu realizacji
- Zmiana współczynnika awarii
- Czas odzyskiwania po nieudanym wdrożeniu
- Współczynnik przeróbek wdrożenia
Z roku na rok badania pokazują, że zespoły o wyższej efektywności częściej wprowadzają zmiany, szybciej przechodzą od zatwierdzenia do środowiska produkcyjnego, szybciej odzyskują sprawność po nieudanych wdrożeniach, a także poświęcają mniej czasu na rozwiązywanie problemów związanych z wdrożeniami. Aby zapoznać się z najnowszymi badaniami i definicjami metryk, zobacz metryki dostarczania oprogramowania DORA.
Wyniki te weryfikują ideę, że praktyki wdrażania mają znaczenie.
Sprawdź swoją wiedzę
Opinia
Czy ta strona była pomocna?
Nie
Potrzebujesz pomocy dotyczącej tego tematu?
Chcesz spróbować użyć asystenta Ask Learn, aby wyjaśnić ten temat lub uzyskać instrukcje, które go dotyczą?