Ćwiczenie — wypychanie zmiany przez potok

Ukończone

W tej części zobaczysz miejsca wdrożenia w akcji. Na stronie głównej witryny internetowej zmieniasz kolor tła i tekst na banerze hero. Następnie wypchniesz zmiany do usługi GitHub, obejrzyj przebieg potoku i zweryfikuj zmiany.

Aby jeszcze bardziej przećwiczyć ten proces, należy przywrócić zmiany i obejrzeć przebieg potoku jako sposób przesyłania dalej.

Zmienianie tekstu na banerze hero

Tutaj zmienisz tekst na banerze hero. Później zobaczysz zmianę podczas wdrażania w usłudze App Service.

1. W programie Visual Studio Code w katalogu Tailspin.SpaceGame.Web/Views/Home otwórz plik Index.cshtml.

2. Poszukaj tego tekstu w górnej części strony:

   <p>An example site for learning</p>
   

   Napiwek

   Program Visual Studio Code umożliwia wyszukiwanie tekstu w plikach. Aby uzyskać dostęp do okienka wyszukiwania, wybierz ikonę lupy w okienku bocznym.

3. Zastąp przykładowy tekst następującym tekstem, a następnie zapisz plik.

   <p>Welcome to the official Space Game site!</p>
   

Zmienianie koloru tła

W tym miejscu zmienisz kolor tła baneru hero z szarego na zielony.

1. W programie Visual Studio Code w katalogu Tailspin.SpaceGame.Web/wwwroot/css otwórz site.scss.

   Ważny

   Otwórz site.scss, a nie site.css. Etap budowania jest uruchamiany node-sass, aby przekonwertować site.scss (plik Sass) na site.css (standardowy plik CSS).

2. Znajdź następujący kod w górnej części pliku:

   .intro {
     height: 350px;
     background-color: #666;
     background-image: url('/images/space-background.svg');
     background-size: 1440px;
     background-position: center top;
     background-repeat: no-repeat;
     background-attachment: fixed;
   

3. W kodzie zastąp wyróżniony tekst, jak pokazano w poniższym przykładzie. Następnie zapisz plik.

   .intro {
     height: 350px;
     background-color: green;
     background-image: url('/images/space-background.svg');
     background-size: 1440px;
     background-position: center top;
     background-repeat: no-repeat;
     background-attachment: fixed;
   

Przepchnij zmiany przez proces

Zwykle należy zbudować i uruchomić stronę lokalnie, żeby sprawdzić zmianę. Możesz również uruchomić wszystkie skojarzone testy jednostkowe, aby sprawdzić, czy zmiana nie przerywa istniejących funkcji.

Dla zwięzłości, tutaj zatwierdź zmiany w swojej gałęzi, prześlij gałąź do GitHub i zobacz przebieg pipeline.

1. Dodaj Index.cshtml i site.scss do indeksu, zatwierdź zmiany, a następnie wypchnij zmiany do usługi GitHub.

   git add Tailspin.SpaceGame.Web/Views/Home/Index.cshtml Tailspin.SpaceGame.Web/wwwroot/css/site.scss
   git commit -m "Change text and colors on the home page"
   git push origin blue-green
   

2. W usłudze Azure Pipelines śledź kompilację na każdym etapie.

3. Przejdź do adresu URL odpowiadającego slotowi produkcyjnemu dla środowiska testowego . To gniazdo jest domyślnym gniazdem, które skonfigurowałeś przy wcześniejszej konfiguracji potoku.

   Zobaczysz, że wdrożona witryna internetowa pokazuje zmiany koloru i tekstu.

   

4. Przejdź do adresu URL odpowiadającego za slot zamiany dla środowiska testowego . Adres URL ma w swojej nazwie człon "-swap.azurewebsites.net".

   Zostanie wyświetlona poprzednia wersja witryny internetowej bez zmiany koloru i tekstu.

   

   Nie widzisz żadnych zmian, ponieważ zamieniono miejsce produkcyjne i miejsce zamiany. Innymi słowy, w tym miejscu zawsze wdrażasz w miejscu wymiany, a następnie zamieniasz miejsce produkcyjne i miejsce wymiany. Proces zamiany gwarantuje, że produkcyjne miejsce wskazuje na nowsze wdrożenie.

Przywróć zmianę

Załóżmy, że wdrożono zmianę, którą chcesz przywrócić. W tym momencie można wycofać zmianę, zamieniając slot produkcyjny z na slot z ponownie. Można na przykład ręcznie zamienić sloty przez Portal Azure. Lub, zamiast wycofywania zmian, możesz przejść do przodu, przepychając kolejną zmianę przez pipeline.

To tutaj zrobisz. Przywrócisz najnowsze zmiany w kodzie i przepchniesz kolejną zmianę przez pipeline. W tym celu użyj polecenia git revert.

W usłudze Git rzadko usuwasz zatwierdzenia z historii pliku. W przeciwieństwie do operacji "cofnij" w edytorze tekstów polecenie git revert tworzy nowe zatwierdzenie, które jest zasadniczo przeciwieństwem określonego zestawu zatwierdzeń. Aby wyświetlić zatwierdzenia, najpierw uruchom polecenie git log, aby śledzić historię zatwierdzeń podczas procesu cofania.

1. W terminalu uruchom następujące polecenie git log, aby wyświetlić historię zatwierdzń.

   git --no-pager log --oneline
   

   Dane wyjściowe są podobne do poniższego przykładu kodu. W danych wyjściowych zobaczysz dodatkowe zatwierdzenia i różne identyfikatory zatwierdzeń.

   d6130b0 (HEAD -> blue-green, origin/blue-green) Change text and colors on the home page
   ce56955 Swap deployment slots
   0d6a123 Trigger the pipeline
   

   W danych wyjściowych prześledź historię zatwierdzń. Najnowsze zatwierdzenie znajduje się na górze.

2. Uruchom następujące polecenie git revert, aby przywrócić jedno zatwierdzenie.

   git revert --no-edit HEAD
   

   Pomyśl o HEAD jako o bieżącym stanie twojej gałęzi. HEAD odnosi się do najnowszego komitu. To polecenie określa, aby przywrócić tylko ostatni commit, czyli HEAD.

3. Uruchom ponownie git log, aby wyświetlić zaktualizowaną historię zatwierdzń.

   git --no-pager log --oneline
   

   Na górze twojego wyniku zobaczysz dodatkowe zatwierdzenie, które cofa poprzednie zatwierdzenie. Oto przykład:

   e58896a (HEAD -> blue-green) Revert "Change text and colors on the home page"
   d6130b0 (origin/blue-green) Change text and colors on the home page
   ce56955 Swap deployment slots
   0d6a123 Trigger the pipeline
   

Pchnij przywróconą zmianę przez pipeline

Tutaj przesyłasz przywróconą zmianę przez potok i obserwujesz wyniki.

1. Uruchom następujące polecenie git push, aby przekazać gałąź blue-green do repozytorium GitHub.

   git push origin blue-green
   

2. W usłudze Azure Pipelines przejdź do kompilacji. Śledź kompilację, gdy się uruchamia.

3. Przejdź do adresów URL odpowiadających zamiany miejsca i miejsca produkcyjnego dla środowiska przejściowego .

   Miejsce w produkcji jest teraz przekierowane do przywróconej wersji, czyli oryginalnej witryny.

   

   Zamiana miejsca wskazuje teraz poprzednią zmianę.

   

Świetna praca! Zespół ma teraz sposób automatyzowania wydań. Użytkownicy mogą uzyskiwać nowe funkcje bez ponoszenia przestojów.

Spotkanie zespołu

Zespół zbiera się, aby zaprezentować pipeline. Tym razem Tim przepycha zmianę przez pipeline'u, podczas gdy wszyscy obserwują. Ale nie wszyscy są przekonani.

Andy: Świetnie jest widzieć miejsca wdrożenia w pracy. Ale nie rozumiem. Jak korzystać z wdrożeń bez przestojów w tym miejscu? Faza Staging jest tylko dla naszego zespołu i kadry zarządzającej.

Tim: Rzeczywiście, nie będziemy teraz widzieć wielu korzyści. Wyobraźmy sobie jednak, co się stanie, gdy zastosujemy wdrożenia niebiesko-zielone do etapu produkcji Production. Nadal będziemy mieli ręczne zatwierdzenie przez zarząd przed podwyższeniem poziomu do Production. Jednak gdy udostępnimy nowe funkcje, proces zamiany sprawi, że wdrożenie będzie niemal natychmiastowe. Będzie ona bezproblemowa dla naszych użytkowników.

Andy: OK, myślę, że rozumiem teraz. Podoba mi się ta poprawa. System miejsc wdrożenia był łatwy do skonfigurowania i przyniesie korzyści naszym użytkownikom. Każdy wygrywa.

Amita: Skoro już mowa o ulepszeniach, może ponownie przyjrzymy się naszemu ćwiczeniu z mapowania strumienia wartości, które wykonaliśmy kilka tygodni temu? Założę się, że zobaczymy postęp w tym, jak szybko możemy wydać nowe funkcje.

Mara: Świetnie, umieśćmy to w porządku obrad na naszym następnym spotkaniu zespołowym.