Übung: Höherstufen in die Test-Phase

8 Minuten

Ihre Release-Pipeline verfügt weiterhin über zwei Phasen, aber sie sind jetzt anders als zuvor. Die Phasen sind Build und Dev. Jede Änderung, die Sie an GitHub übertragen, löst die Buildphase aus, damit sie ausgeführt wird. Die Dev-Phase wird nur ausgeführt, wenn die Änderung im Releasebranch erfolgt. Hier fügen Sie der Pipeline die Testphase hinzu.

Denken Sie daran, dass das Team beschlossen hat, jeden Morgen um 3 Uhr morgens einen geplanten Trigger zu verwenden, um den Build von der Dev-Phase in die Test-Phase zu überführen. So richten Sie den geplanten Trigger ein:

Definieren Sie den Zeitplan in Ihrer Buildkonfiguration.
Definieren Sie die Test-Stufe, die eine Bedingung enthält, die die Stufe nur ausführt, wenn der Grund des Builds als Schedule markiert ist.

Für Lernzwecke definieren Sie hier den Zeitplan, ermöglichen jedoch, dass der Build direkt von Dev zu Test wechselt. Dieses Setup vermeidet die Notwendigkeit, auf das Auslösen des Zeitplans zu warten. Nachdem Sie dieses Modul abgeschlossen haben, versuchen Sie, mit verschiedenen Cron-Ausdrücken zu experimentieren, um die Testphase nur zur geplanten Zeit auszuführen.

Höherstufen von Änderungen in die Test-Phase

Hier ändern Sie Ihre Pipelinekonfiguration so, dass der Build in der Testphase bereitgestellt wird.

Ändern Sie in Visual Studio Code azure-pipelines.yml wie folgt:

trigger:
- '*'

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

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false 

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'

- stage: 'Test'
  displayName: 'Deploy to the test environment'
  dependsOn: Dev
  #condition: eq(variables['Build.Reason'], 'Schedule')
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: test
    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: '$(WebAppNameTest)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

Der schedules Abschnitt definiert einen Cron-Ausdruck. Sie können mehr als einen Ausdruck in Ihrer Konfiguration definieren. Der Ausdruck löst die Pipeline aus, damit sie jeden Tag um 3 Uhr morgens für den Releasebranch ausgeführt wird. Das always-Flag wird auf false gesetzt, damit die Pipeline nur dann ausgeführt wird, wenn der Release-Branch Änderungen aus dem vorherigen Lauf enthält.

Die Test-Phase definiert eine Bedingung, durch die die Phase nur ausgeführt wird, wenn der Buildgrund Schedule lautet. (Die integrierte Variable Build.Reason definiert den Buildgrund.) Wenn diese Bedingung FALSE ist, wird die Phase übersprungen, aber die vorherigen Phasen werden weiter ausgeführt.

Hinweis

Diese Bedingung wird zu Lernzwecken angezeigt. Sie ist kommentiert, damit die Änderung von Dev in Test verschoben kann, ohne auf die Auslösung des Zeitplans warten zu müssen.

Fügen Sie im integrierten Terminal dem Index azure-pipelines.yml hinzu. Committen Sie dann die Änderung, und pushen Sie sie auf GitHub.

Tipp

Speichern Sie azure-pipelines.yml, bevor Sie diese Git-Befehle ausführen.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Test stage"
git push origin release
```
Wechseln Sie in Azure Pipelines zum Build. Überwachen Sie die Ausführung des Builds.
Nachdem der Build abgeschlossen ist, wählen Sie die Schaltfläche "Zurück" aus, um zur Zusammenfassungsseite zurückzukehren.

Sie sehen, dass die Bereitstellung erfolgreich abgeschlossen wurde.
Wechseln Sie in einem Webbrowser zu der URL, die der App Service-Instanz für Ihre Testumgebung zugeordnet ist.

Wenn die Browserregisterkarte noch geöffnet ist, aktualisieren Sie die Seite. Wenn Sie sich die URL nicht merken, suchen Sie sie im Azure-Portal auf der Seite " App Service-Details ".

Sie sehen, dass die Space-Game-Website für App Service bereitgestellt wurde und läuft.
Wählen Sie als optionalen Schritt in Azure-Pipelines "Umgebungen" aus. Wählen Sie dann die Testumgebung aus.

Azure Pipelines zeichnet Ihren Bereitstellungsverlauf auf. Im Verlauf können Sie Änderungen in der Umgebung auf Code-Commits und Arbeitsaufgaben zurückverfolgen.

Andy und Mara fügen der Pipeline die Testphase hinzu. Sie zeigen die Ergebnisse an Amita.

Amita: Ich mag, dass Änderungen erstellt und bereitgestellt werden, damit ich sie jeden Morgen testen kann. Aber ich sehe nicht, wie ich steuern kann, wann Änderungen bei Staging eingehen.

Mara: Ja, die Bereitstellung durch Automatisierung spart viel Zeit. Denken Sie daran, dass wir nur den geplanten Trigger eingeschlossen haben. Fügen wir eine Freigabegenehmigung für Sie hinzu, wenn wir die Staging-Umgebung für Tim einrichten. Auf diese Weise werden Änderungen erst dann in die Staging-Phase übertragen, wenn Sie bereit sind.

Übung: Höherstufen in die Test-Phase

Höherstufen von Änderungen in die Test-Phase

Feedback