Streszczenie

  • 3 min

W tym module zdefiniowano wzorzec wdrażania jako zautomatyzowany sposób bezproblemowego wdrażania nowych funkcji aplikacji dla użytkowników. Dobry wzorzec wdrażania może pomóc zminimalizować przestoje. Umożliwia również stopniowe wdrażanie nowych funkcji użytkownikom.

Możesz wybrać spośród kilku wzorców wdrażania. Wybrany wzorzec wdrożenia zależy od przyczyn wdrożenia i zasobów. Czy masz wprowadzonych testerów kanarków? Czy zastosujesz cichą premierę i wybierzesz testerów, którzy nie wiedzą, że nimi są? Jeśli masz zaufany zespół testerów, który stopniowo zwiększa się od małej grupy do większej, możesz wybrać wdrożenie z progresywnym ujawnianiem. Jeśli chcesz też wiedzieć, czy jedna wersja działa lepiej niż inna, możesz wybrać testowanie A/B.

Zespół Tailspin zdecydował się zaimplementować niebieski zielony wzorzec wdrażania przy użyciu miejsc wdrożenia w usłudze Azure App Service. Sloty wdrożeniowe to działające aplikacje, które mają własne nazwy hostów. Zespół może zamienić dwa miejsca wdrożenia. Zamieniając się, mogą one natychmiast promować zmiany w środowisku produkcyjnym. Mimo że zespół nie jest gotowy do udostępnienia swojej witryny internetowej publicznie, udowodnili, że mogą oni uzyskać nowe funkcje dla swoich użytkowników bez ponoszenia przestojów.

W tym module pokazano również, jak anulować niezamierzoną zmianę, przywracając commit Git, a następnie przekazać przywróconą zmianę przez potok.

Jak wypada zespół?

W module Ocena istniejącego procesu tworzenia oprogramowania mara wykonała ćwiczenie mapowania strumienia wartości . Ćwiczenie pomogło zespołowi przeanalizować bieżący proces cyklu wydania.

Pamiętaj, że współczynnik aktywności , czyli wydajność, to czas procesu podzielony przez łączny czas realizacji.

$${Współczynnik aktywności\ =\ }{\dfrac{Czas\ procesu}{Całkowity\ czas\ realizacji}}$$

Zespół internetowy Tailspin na początku używał tej metryki, aby ustalić, że byli 23-procentowo wydajni.

Zespół po raz pierwszy zmniejszył pewne nieefektywności, gdy zaimplementowali ciągłą integrację. Dzięki zastosowaniu ciągłego dostarczania (CD) jeszcze bardziej zredukowali nieefektywności.

W poprzednich ścieżkach szkoleniowych zespół zmniejszył:

  • Czas potrzebny na skonfigurowanie kontroli źródła dla nowych funkcji. Wymagany czas zmienił się z trzech dni do zera dni.

    Zespół osiągnął tę poprawę, przechodząc z scentralizowanej kontroli źródła do usługi Git, czyli formy rozproszonej kontroli źródła. Za pomocą rozproszonej kontroli źródła nie muszą czekać na odblokowanie plików.

  • Czas potrzebny na dostarczenie kodu do Amita, testera. Wymagany czas z dwóch dni na zero dni.

    Zespół osiągnął tę poprawę, przenosząc proces kompilacji do usługi Azure Pipelines. Azure Pipelines automatycznie powiadamia Amitę, gdy kompilacja jest dostępna. Deweloperzy nie muszą już aktualizować arkusza kalkulacyjnego Amity, aby ją powiadomić.

  • Czas, jaki Amita poświęca na testowanie nowych funkcji. Wymagany czas zmniejszył się z trzech dni do jednego dnia.

    Zespół osiągnął to ulepszenie poprzez testy jednostkowe ich kodu. Uruchamiają testy jednostkowe za każdym razem, gdy zmiana przechodzi przez proces kompilacji, więc mniej usterek i regresji dociera do Amity. Zmniejszone obciążenie oznacza, że Amita może wykonać każdy test ręczny szybciej.

Potok wydania utworzony przez Ciebie i zespół w ramach tej ścieżki szkoleniowej zmniejszył się:

  • Czas potrzebny na przeniesienie kompilacji do etapu Test. Wymagany czas zmienił się z trzy dni na jeden dzień.

    Zespół osiągnął to za pomocą zaplanowanego wyzwalacza do wdrożenia w Test codziennie o godzinie 3:00.

  • Czas potrzebny na wprowadzenie przetestowanej kompilacji do etapu staging . Wymagany czas zmienił się z dwóch dni na zero dni.

    Zespół osiągnął tę poprawę, dodając do etapu testowego testy interfejsu użytkownika Selenium, formę testowania funkcjonalnego. Te testy automatyczne są znacznie szybsze niż wersje ręczne.

  • Czas potrzebny na uzyskanie zatwierdzonej wersji z Staging do produkcji. Wymagany czas zmienił się z jeden dzień do mniej niż jeden dzień.

    Zespół osiągnął tę poprawę, dodając ręczne etapy zatwierdzania do procesu. Gdy zarząd zatwierdzi, Tim może wdrożyć zmiany z Środowisko testowe na produkcję.

Te zmiany zmniejszają całkowity czas realizacji z 22 dni do 10 dni. Po zastąpieniu tych liczb równaniem:

$${Współczynnik aktywności\ =\ }{\dfrac{5\ dni}{10\ dni}}{ = 0,50}$$

Pomnoż wynik przez 100 procent, a otrzymujemy redukcję o 50 procent.

Chociaż zawsze jest miejsce na poprawę, ta zmiana jest wygraną dla zespołu. Nie tylko klienci otrzymują wartość szybciej, zespół Tailspin poświęca teraz mniej czasu na czekanie i więcej czasu na wykonywanie tego, co najbardziej lubią: dostarczanie funkcji, które wiedzą, że ich klienci będą kochać.

Dowiedz się więcej

Skorzystaj z tych dodatkowych zasobów, aby dowiedzieć się więcej na temat usługi App Service, miejsc wdrożenia i wycofywania zmian: