Podsumowanie

  • 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 testerów kanargu? Czy zastosować ciemny start i wybrać testerów, którzy nie wiedzą, że są testerami? Jeśli masz zaufany zestaw testerów, który stopniowo zwiększa się z małego zestawu do większego zestawu, możesz wybrać wdrożenie progresywne ekspozycji. 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 aplikacja systemu Azure. Miejsca wdrożenia to aplikacje na żywo, 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 przerzucić niezamierzoną zmianę, przywracając zatwierdzenie usługi Git, a następnie wypychając przywróconą zmianę przez potok.

Jak radzi sobie 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 lub wydajność to czas procesu podzielony przez całkowity czas realizacji:

$${współczynnik\ aktywności\ =\ }{\dfrac{czas\ procesu}{całkowity\ czas\ realizacji}}$$

Zespół internetowy Tailspin początkowo używał tej metryki, aby ustalić, że były one o 23 procent wydajne.

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

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

  • Czas potrzebny na skonfigurowanie kontroli źródła dla nowych funkcji. Wymagany czas trwał od trzech dni do zera.

    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 trwał od dwóch dni do zera.

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

  • Czas potrzebny Amita na przetestowanie nowych funkcji. Wymagany czas trwał od trzech dni do jednego dnia.

    Zespół osiągnął to ulepszenie przez testowanie jednostkowe kodu. Uruchamiają testy jednostkowe za każdym razem, gdy zmiana przechodzi przez potok kompilacji, więc mniej usterek i regresji dociera do Amita. 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ły się:

  • Czas potrzebny na pobranie kompilacji do etapu testowego. Wymagany czas trwał od trzech dni do jednego dnia.

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

  • Czas potrzebny na przetestowaną kompilację w środowisku przejściowym. Wymagany czas trwał od dwóch dni do zera.

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

  • Czas potrzebny na uzyskanie zatwierdzonej kompilacji ze środowiska przejściowego na żywo. Wymagany czas trwał od jednego dnia do mniej niż jednego dnia.

    Zespół osiągnął tę poprawę, dodając testy ręcznego zatwierdzania do potoku. Gdy kierownictwo się wyłączy, Tim może zwolnić zmiany z Staging na live.

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żymy wynik o 100 procent i otrzymujemy 50 procent redukcji.

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: