Övning – Flytta upp till Utvecklingssteget

8 minuter

Teamet har en plan och är redo att börja implementera sin versionspipeline. Ditt Azure DevOps-projekt har konfigurerats och dina Azure App Service-instanser är redo att ta emot byggartefakter.

Kom nu ihåg att teamets pipeline bara har två steg. Den första fasen genererar byggartefakten. Den andra fasen distribuerar Webbappen Space Game till App Service. Här följer du med Andy och Mara när de ändrar pipelinen. De kommer att distribueras till App Service-miljön som motsvarar Utvecklingsfasen .

Utvecklingssteget liknar distributionssteget som du gjorde i modulen Skapa en versionspipeline i Azure Pipelines. Där använde du en CI-utlösare för att starta byggprocessen. Här gör du samma sak.

Hämta grenen från GitHub

Här hämtar du grenen release från GitHub. Du kan också checka ut eller växla till grenen.

Den här grenen fungerar som din versionsgren . Den innehåller space game-projektet som användes i tidigare moduler. Den innehåller också en Azure Pipelines-konfiguration att börja med.

Så här hämtar och växlar du till grenen:

Öppna den integrerade terminalen i Visual Studio Code.
Om du vill hämta en gren med namnet release från Microsoft-lagringsplatsen och växla till den grenen kör du följande git kommandon.
```
git fetch upstream release
git checkout -B release upstream/release
```
Med formatet för dessa kommandon kan du hämta startkod från Microsoft GitHub-lagringsplatsen, som upstreamkallas . Snart ska du skicka den här grenen till din GitHub-lagringsplats, som originkallas .
Som ett valfritt steg öppnar du azure-pipelines.yml från Visual Studio Code. Bekanta dig med den inledande konfigurationen.

Konfigurationen liknar den grundläggande som du skapade i modulen Skapa en versionspipeline med Azure Pipelines . Den bygger bara appens versionskonfiguration. I utbildningssyfte kör den här konfigurationen inte de kvalitets- eller säkerhetskontroller som du har konfigurerat i tidigare moduler.

Kommentar

En mer robust konfiguration kan ange de grenar som deltar i byggprocessen. För att till exempel verifiera kodkvaliteten kan du köra enhetstester varje gång du push-överför en ändring på en gren. Du kan också distribuera programmet till en miljö som utför mer omfattande testning. Men du gör bara den här distributionen när du har en pull-begäran, när du har en versionskandidat eller när du sammanfogar kod till main.

Mer information finns i Implementera ett kodarbetsflöde i din byggpipeline med hjälp av Git- och GitHub - och Build-pipelineutlösare.

Flytta upp ändringar i Utvecklingssteget

Här ändrar du pipelinekonfigurationen för att höja upp bygget till Utvecklingssteget.

Ändra azure-pipelines.yml i Visual Studio Code.

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'

Den här konfigurationen liknar den som du skapade i föregående modul. Där har du och teamet skapat ett konceptbevis för kontinuerlig distribution. Observera dock dessa skillnader, som är markerade i föregående kodexempel:

Den här konfigurationen definierar variabler i början av filen. Variablerna används i hela pipelinen. De definierar vilken konfiguration som ska skapas (Release). De definierar också namnet på versionsgrenen (release).
Distributionssteget från konceptbeviset heter nu Dev.
Dev-fasen använder ett villkor som dirigerar systemet att köra fasen endast när föregående steg lyckas och den aktuella grenen är release. Den här konfigurationen säkerställer att versionsfunktioner endast distribueras till Dev-miljön .
Distributionssteget använder variabeln WebAppNameDev för att distribuera till App Service-instansen som är associerad med Dev-miljön .

Kommentar

I praktiken kan du distribuera från någon annan gren, till exempel main. Du kan inkludera logik som gör att ändringar kan höjas upp till Utvecklingssteget från flera grenar, till exempel release och main.

Från den integrerade terminalen lägger du till azure-pipelines.yml i indexet. Genomför ändringen och push-överför den till GitHub.

Dricks

Innan du kör de här Git-kommandona sparar du azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev stage"
git push origin release
```
I Azure Pipelines går du till versionen. Spåra bygget när det körs.
När bygget är klart går du tillbaka till sammanfattningssidan genom att välja bakåtknappen.

Du ser att distributionen har slutförts.
Från en webbläsare går du till url:en som är associerad med App Service-instansen för din Dev-miljö .

Om du fortfarande har webbläsarfliken öppen uppdaterar du sidan. Om du inte kommer ihåg URL:en hittar du den i Azure-portalen på sidan App Service-information .

Du ser att webbplatsen Space Game distribueras till App Service och körs.
Som ett valfritt steg väljer du Miljöer i Azure Pipelines. Välj sedan utvecklingsmiljön .

Azure Pipelines registrerar distributionshistoriken. I historiken kan du spåra miljöns ändringar tillbaka till kodincheckningar och arbetsobjekt.

Övning – Flytta upp till Utvecklingssteget

Hämta grenen från GitHub

Flytta upp ändringar i Utvecklingssteget

Feedback