Ćwiczenie — tworzenie żądania ściągnięcia

Ukończone

W tej lekcji przećwiczysz proces przesyłania żądania ściągnięcia i scalania zmian w main gałęzi, aby wszyscy mogli korzystać z pracy.

Mimo że gałąź generuje artefakt kompilacji, ta praca istnieje tylko w build-pipeline gałęzi. Należy scalić gałąź z gałęzią main .

Pamiętaj, że pull request informuje innych deweloperów, że masz gotowy kod do przejrzenia, jeśli to konieczne, i chcesz, aby zmiany zostały scalone z inną gałęzią, na przykład main.

Zanim rozpoczniemy, sprawdźmy, co robią Mara i Andy.

Andy: Cześć, Mara. Wiem, że masz uruchomiony potok kompilacji w usłudze Azure. Dodaję funkcję do witryny internetowej i chcę zobaczyć proces kompilacji. Czy możemy to zrobić?

Mara: Absolutnie. Utworzyłam potok dla gałęzi. Dlaczego nie tworzymy żądania ściągnięcia i nie scalamy go w main taki sposób, aby można było również użyć potoku?

Andy: Brzmi świetnie. Zobaczmy.

Tworzenie gałęzi i dodawanie kodu początkowego

Chociaż możesz użyć potoku kompilacji utworzonego w poprzednim module, utwórzmy nową gałąź o nazwie code-workflow. Ta gałąź jest oparta na metodzie main, dzięki czemu można ćwiczyć proces od początku.

1. W programie Visual Studio Code otwórz zintegrowany terminal.

2. Przejdź do main gałęzi:

   git checkout main
   

3. Upewnij się, że masz najnowszą wersję kodu z usługi GitHub:

   git pull origin main
   

4. Utwórz gałąź o nazwie code-workflow:

   git checkout -B code-workflow
   

   Argument -b wskazuje, że jeśli nowa gałąź nie istnieje, należy ją utworzyć. Pomiń argument -b, gdy chcesz przełączyć się na istniejącą gałąź.

   Domyślnie nowa gałąź jest oparta na poprzedniej gałęzi, w której uruchomiono polecenie git checkout. W tym miejscu gałąź nadrzędna to main, ale gałąź nadrzędna może być inna, na przykład gałąź funkcji uruchomiona przez inną osobę, z którą chcesz budować lub eksperymentować.

   Teraz możesz bezpiecznie wprowadzić wszelkie potrzebne zmiany, ponieważ jesteś we własnej gałęzi lokalnej. Jeśli chcesz zobaczyć, która gałąź jest włączona, uruchom polecenie git branch -v.

5. W Eksploratorze plików otwórz azure-pipelines.yml i zastąp jego zawartość następującymi elementami:

   trigger:
   - '*'
   
   pool:
     vmImage: 'ubuntu-20.04'
     demands:
     - npm
   
   variables:
     buildConfiguration: 'Release'
     wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
     dotnetSdkVersion: '6.x'
   
   steps:
   - task: UseDotNet@2
     displayName: 'Use .NET SDK $(dotnetSdkVersion)'
     inputs:
       version: '$(dotnetSdkVersion)'
   
   - task: Npm@1
     displayName: 'Run npm install'
     inputs:
       verbose: false
   
   - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
     displayName: 'Compile Sass assets'
   
   - task: gulp@1
     displayName: 'Run gulp tasks'
   
   - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
     displayName: 'Write build info'
     workingDirectory: $(wwwrootDir)
   
   - task: DotNetCoreCLI@2
     displayName: 'Restore project dependencies'
     inputs:
       command: 'restore'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Build the project - $(buildConfiguration)'
     inputs:
       command: 'build'
       arguments: '--no-restore --configuration $(buildConfiguration)'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Publish the project - $(buildConfiguration)'
     inputs:
       command: 'publish'
       projects: '**/*.csproj'
       publishWebProjects: false
       arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
       zipAfterPublish: true
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

   Ta konfiguracja przypomina podstawową utworzoną w poprzednim module. W przypadku zwięzłości kompiluje tylko konfigurację wydania projektu.

Wypychanie gałęzi do repozytorium GitHub

W tym miejscu wypchniesz gałąź code-workflow do usługi GitHub i zobaczysz, jak usługa Azure Pipelines skompiluje aplikację.

1. W terminalu uruchom polecenie git status , aby zobaczyć, co istnieje w gałęzi niezatwierdzonej pracy:

   git status
   

   Zobaczysz, że azure-pipelines.yml został zmodyfikowany. Wkrótce zatwierdzisz to w swojej gałęzi, ale najpierw musisz się upewnić, że Git śledzi ten plik, który nazywa się staging.

   Zmiany etapowe są zatwierdzane tylko po uruchomieniu polecenia git commit. Następnie uruchom polecenie git add , aby dodać azure-pipelines.yml do obszaru przejściowego lub indeksu.

2. Uruchom następujące git add polecenie, aby dodać azure-pipelines.yml do obszaru przejściowego:

   git add azure-pipelines.yml
   

3. Uruchom następujące git commit polecenie, aby zatwierdzić przygotowany plik w code-workflow gałęzi:

   git commit -m "Add the build configuration"
   

   Argument -m określa komunikat dotyczący zatwierdzenia. Ten komunikat stanie się częścią historii zmienionego pliku. Pomaga on recenzentom zrozumieć zmianę i pomaga przyszłym opiekunom zrozumieć, jak plik zmienił się wraz z upływem czasu.

   Napiwek

   Najlepsze komunikaty zatwierdzenia zakończą zdanie "Jeśli zastosujesz to zatwierdzenie, będziesz ..."

   Jeśli pominiesz argument -m system Git uruchomi edytor tekstu, w którym można wprowadzić szczegóły zmiany. Ta opcja jest przydatna, gdy trzeba wprowadzić komunikat zawierający wiele wierszy tekstu. Tekst przed pierwszym pustym wierszem jest tytułem zatwierdzenia.

4. Uruchom to git push polecenie, aby wypchnąć lub przekazać code-workflow gałąź do repozytorium w usłudze GitHub:

   git push origin code-workflow
   

5. Opcjonalnie przejdź do projektu w usłudze Azure Pipelines i prześledź kompilację podczas jej uruchamiania.

   Nazywa się to buildem CI. Konfiguracja potoku używa wyzwalacza do kontrolowania gałęzi uczestniczących w procesie kompilacji. W tym miejscu "*" określa wszystkie gałęzie.

   trigger:
   - '*'
   

   Później zobaczysz, jak kontrolować konfigurację potoku w celu kompilacji tylko z potrzebnych gałęzi.

   Zobaczysz, że kompilacja zakończy się pomyślnie i utworzy artefakt zawierający utworzoną aplikację internetową.

Tworzenie żądania ściągnięcia

W tym miejscu utworzysz żądanie ściągnięcia dla gałęzi:

1. W przeglądarce zaloguj się do usługi GitHub.

2. Przejdź do repozytorium mslearn-tailspin-spacegame-web .

3. Z listy rozwijanej Gałąź wybierz gałąź code-workflow .

   

4. Aby rozpocząć pull request, wybierz pozycję Współtworzenie, a następnie Otwórz pull request.

   

5. Upewnij się, że baza określa rozwidlenie repozytorium, a nie repozytorium firmy Microsoft.

   Wybór wygląda następująco:

   

   Ważne

   Ten krok jest ważny, ponieważ nie można scalić zmian w repozytorium firmy Microsoft. Upewnij się, że repozytorium podstawowe wskazuje konto usługi GitHub, a nie MicrosoftDocs.

   Jeśli skończysz z pull requestem w repozytorium MicrosoftDocs, zamknij pull request i powtórz te czynności.

   Ten proces obejmuje dodatkowy krok, ponieważ pracujesz z rozwidlenia repozytorium. Gdy pracujesz bezpośrednio z własnym repozytorium, a nie z rozwidleniem, domyślnie wybrana jest gałąź main.

6. Wprowadź tytuł i opis żądania ściągnięcia.

   • Tytuł:

     Konfigurowanie usługi Azure Pipelines

   • Opis rozwiązania:

     Ta konfiguracja potoku kompilacyjnego buduje aplikację i tworzy kompilację w konfiguracji Release.

7. Aby ukończyć żądanie ściągnięcia, wybierz pozycję Utwórz żądanie ściągnięcia.

   Ten krok nie scala żadnego kodu. Informuje inne osoby, że proponowane zmiany mają zostać scalone z gałęzią main .

   

   Zostanie wyświetlone okno żądania ściągnięcia. Stan kompilacji w usłudze Azure Pipelines jest skonfigurowany do wyświetlania w ramach żądania ściągnięcia. Dzięki temu ty i inni użytkownicy mogą wyświetlać stan kompilacji podczas jej działania.

   

   Podobnie jak podczas wypychania gałęzi do usługi GitHub, żądanie ściągnięcia domyślnie wyzwala usługę Microsoft Azure Pipelines w celu skompilowania aplikacji.

   Napiwek

   Jeśli stan kompilacji nie zostanie wyświetlony od razu, zaczekaj chwilę lub odśwież stronę.

8. Opcjonalnie wybierz link Szczegóły, a następnie prześledź kompilację, gdy przechodzi przez potok.

   Możesz przekazać kompilację na następny etap procesu, na przykład do kontroli jakości. Później możesz skonfigurować potok, tak aby zmiany były wypychane aż do etapu kontroli jakości lub produkcji.

9. Wróć do żądania ściągnięcia w usłudze GitHub.

   Poczekaj na zakończenie kompilacji. Teraz możesz scalić żądanie ściągnięcia.

   

10. Wybierz pozycję Scal żądanie ściągnięcia, a następnie wybierz pozycję Potwierdź scalanie.

11. Aby usunąć code-workflow gałąź z usługi GitHub, wybierz pozycję Usuń gałąź.

    

    Po scaleniu żądania ściągnięcia można całkowicie bezpiecznie usunąć gałąź z usługi GitHub. W rzeczywistości jest to powszechna praktyka, ponieważ gałąź nie jest już potrzebna. Zmiany zostały scalone i nadal można znaleźć szczegółowe informacje o zmianach na GitHub lub w wierszu polecenia. Usunięcie scalonej gałęzi pomaga również innym osobom wyświetlać tylko pracę, która jest obecnie aktywna.

    Gałęzie usługi Git mają być krótkotrwałe. Po scaleniu gałęzi nie wypchniesz do niej dodatkowych zatwierdzeń ani nie scalisz jej po raz drugi. W większości przypadków za każdym razem, gdy uruchamiasz nową funkcję lub poprawkę usterek, zaczynasz od czystej gałęzi opartej main na gałęzi.

    Usunięcie gałęzi w usłudze GitHub nie powoduje usunięcia jej z systemu lokalnego. Aby to zrobić, należy dodać przełącznik -d do polecenia git branch.

Ile razy zmiany są kompilowane?

Zależy to od zdefiniowanej konfiguracji kompilacji. Usługa Azure Pipelines umożliwia definiowanie wyzwalaczy , które określają, które zdarzenia powodują wystąpienie kompilacji. W ten sposób można zdecydować, które gałęzie mają być kompilowane oraz które pliki wyzwalają proces kompilacji.

Załóżmy na przykład, że chcesz, aby kompilacja miała miejsce, gdy zmiana zostanie wypchnięta do usługi GitHub w dowolnej gałęzi git. Nie chcesz jednak, aby kompilacja miała miejsce, gdy jedynymi zmianami są pliki w folderze dokumentacji projektu. Możesz uwzględnić tę trigger sekcję w konfiguracji kompilacji:

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

Domyślnie kompilacja jest wyzwalana po wypchnięciu zmiany do dowolnego pliku w dowolnej gałęzi.

Kompilacja ciągłej integracji to proces budowania, który jest uruchamiany, gdy przesyłasz zmianę do gałęzi.

Budowanie pull requesta (PR) to proces budowania uruchamiany podczas otwierania pull requesta lub wypychania dodatkowych zmian do istniejącego pull requesta.

Zmiany wprowadzone w code-workflow gałęzi są tworzone w trzech warunkach:

• Kompilacja CI uruchamia się po wypchnięciu zmian do gałęzi code-workflow.
• Kompilacja PR ma miejsce po otwarciu żądania ściągnięcia w gałęzi code-workflow dla gałęzi main branch.
• Ostateczna kompilacja ciągłej integracji odbywa się po scaleniu żądania ściągnięcia z gałęzią main .

Kompilacje PR ułatwiają sprawdzenie, czy proponowane zmiany będą działać poprawnie po scaleniu z main inną gałęzią docelową.

Końcowa kompilacja CI pozwala upewnić się, że zmiany są prawidłowe po scaleniu wersji PR.

Opcjonalnie przejdź do usługi Azure Pipelines i obejrzyj ostatnią kompilację main ciągłej integracji w gałęzi.