Ćwiczenie — podwyższanie poziomu do etapu deweloperskiego

8 min

Zespół ma plan i jest gotowy do rozpoczęcia wdrażania potoku wydania. Projekt usługi Azure DevOps został skonfigurowany, a wystąpienia usługi aplikacja systemu Azure są gotowe do odbierania artefaktów kompilacji.

Pamiętaj, że potok zespołu ma tylko dwa etapy. Pierwszy etap tworzy artefakt kompilacji. Drugi etap wdraża aplikację internetową Space Game w usłudze App Service. W tym miejscu należy postępować zgodnie z instrukcjami Andy i Mara podczas modyfikowania potoku. Zostaną one wdrożone w środowisku usługi App Service, które odpowiada etapowi deweloperskiemu.

Etap deweloperski przypomina etap wdrażania utworzony w module Tworzenie potoku wydania w usłudze Azure Pipelines. W tym miejscu użyto wyzwalacza ciągłej integracji, aby rozpocząć proces kompilacji. W tym miejscu robisz to samo.

Pobieranie gałęzi z repozytorium GitHub

W tym miejscu pobierzesz release gałąź z usługi GitHub. Możesz również wyewidencjonować gałąź lub przełączyć się do tej gałęzi.

Ta gałąź służy jako gałąź wydania . Zawiera projekt Space Game używany w poprzednich modułach. Zawiera również konfigurację usługi Azure Pipelines, od których należy zacząć.

Aby pobrać i przełączyć się do gałęzi:

W programie Visual Studio Code otwórz zintegrowany terminal.
Aby pobrać gałąź o nazwie release z repozytorium Firmy Microsoft i przełączyć się do tej gałęzi, uruchom następujące git polecenia.
```
git fetch upstream release
git checkout -B release upstream/release
```
Format tych poleceń umożliwia pobranie kodu początkowego z repozytorium Microsoft GitHub, znanego jako upstream. Wkrótce wypchniesz tę gałąź do repozytorium GitHub o nazwie origin.
Opcjonalnie w programie Visual Studio Code otwórz plik azure-pipelines.yml. Zapoznaj się z początkową konfiguracją.

Konfiguracja jest podobna do podstawowej utworzonej w module Tworzenie potoku wydania za pomocą usługi Azure Pipelines . Kompiluje tylko konfigurację wydania aplikacji. W celach szkoleniowych ta konfiguracja nie uruchamia kontroli jakości ani zabezpieczeń skonfigurowanych w poprzednich modułach.

Uwaga

Bardziej niezawodna konfiguracja może określać gałęzie, które uczestniczą w procesie kompilacji. Na przykład w celu sprawdzenia jakości kodu można uruchamiać testy jednostkowe za każdym razem, gdy wypchniesz zmianę w dowolnej gałęzi. Możesz również wdrożyć aplikację w środowisku, które wykonuje bardziej wyczerpujące testowanie. Jednak to wdrożenie jest możliwe tylko wtedy, gdy masz żądanie ściągnięcia, gdy masz kandydata do wydania lub gdy scalasz kod z główną wersją.

Aby uzyskać więcej informacji, zobacz Implementowanie przepływu pracy kodu w potoku kompilacji przy użyciu wyzwalaczy git i GitHub i potoku kompilacji.

Podwyższanie poziomu zmian do etapu deweloperskiego

W tym miejscu zmodyfikujesz konfigurację potoku, aby podwyższyć poziom kompilacji do etapu deweloperskiego.

W programie Visual Studio Code zmodyfikuj plik azure-pipelines.yml.

trigger:
- '*'

variables:
  buildConfiguration: 'Release'
  releaseBranchName: 'release'

stages:
- stage: 'Build'
  displayName: 'Build the web application'
  jobs: 
  - job: 'Build'
    displayName: 'Build job'
    pool:
      vmImage: 'ubuntu-20.04'
      demands:
      - npm

    variables:
      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

    - publish: '$(Build.ArtifactStagingDirectory)'
      artifact: drop

- stage: 'Dev'
  displayName: 'Deploy to the dev environment'
  dependsOn: Build
  condition: |
    and
    (
      succeeded(),
      eq(variables['Build.SourceBranchName'], variables['releaseBranchName'])
    )
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            displayName: 'Azure App Service Deploy: website'
            inputs:
              azureSubscription: 'Resource Manager - Tailspin - Space Game'
              appName: '$(WebAppNameDev)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

Ta konfiguracja przypomina tę, która została utworzona w poprzednim module. W tym miejscu ty i zespół utworzyli weryfikację koncepcji ciągłego wdrażania. Zwróć jednak uwagę na te różnice, które zostały wyróżnione w poprzednim przykładzie kodu:

Ta konfiguracja definiuje zmienne na początku pliku. Zmienne są używane w całym potoku. Definiują konfigurację do skompilowania (Release). Definiują również nazwę gałęzi wydania (release).
Etap Wdrażania z weryfikacji koncepcji nosi teraz nazwę Dev.
Etap deweloperski używa warunku, który kieruje system do uruchomienia etapu tylko wtedy, gdy poprzedni etap zakończy się powodzeniem, a bieżąca gałąź to release. Ta konfiguracja zapewnia, że funkcje wydania są wdrażane tylko w środowisku deweloperskim.
Krok wdrażania używa zmiennej WebAppNameDev do wdrożenia w wystąpieniu usługi App Service skojarzonym ze środowiskiem deweloperskim.

Uwaga

W praktyce można wdrożyć z innej gałęzi, takiej jak main. Można uwzględnić logikę, która umożliwia podwyższenie poziomu zmian do etapu deweloperskiego z wielu gałęzi, takich jak release i main.

W zintegrowanym terminalu dodaj plik azure-pipelines.yml do indeksu. Zatwierdź zmianę i wypchnij ją do usługi GitHub.

Napiwek

Przed uruchomieniem tych poleceń usługi Git zapisz plik azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev stage"
git push origin release
```
W usłudze Azure Pipelines przejdź do kompilacji. Podczas jego uruchamiania śledź kompilację.
Po zakończeniu kompilacji, aby powrócić do strony podsumowania, wybierz przycisk Wstecz.

Zobaczysz, że wdrożenie zakończyło się pomyślnie.
W przeglądarce internetowej przejdź do adresu URL skojarzonego z wystąpieniem usługi App Service dla środowiska deweloperskiego .

Jeśli nadal masz otwartą kartę przeglądarki, odśwież stronę. Jeśli nie pamiętasz adresu URL, znajdź go w witrynie Azure Portal na stronie szczegółów usługi App Service.

Zobaczysz, że witryna internetowa Space Game jest wdrożona w usłudze App Service i działa.
Opcjonalnie w usłudze Azure Pipelines wybierz pozycję Środowiska. Następnie wybierz środowisko deweloperskie.

Usługa Azure Pipelines rejestruje historię wdrażania. W historii można śledzić zmiany środowiska z powrotem do zatwierdzeń kodu i elementów roboczych.

Ćwiczenie — podwyższanie poziomu do etapu deweloperskiego

Pobieranie gałęzi z repozytorium GitHub

Podwyższanie poziomu zmian do etapu deweloperskiego

Opinia