Ö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 Space Game webbapp till App Service. Här följer du med Andy och Mara när de ändrar pipelinen. De ska distribueras till App Service-miljön som motsvarar fasen Dev.

Steget Dev 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 release-grenen från GitHub. Du kan också checka ut eller växla till grenen.

Den här grenen tjänar som din release gren. Den innehåller projektet Space Game 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 kallas upstream. Snart kommer du att skicka den här grenen till din GitHub-lagringsplats, som kallas origin.
Som ett valfritt steg öppnar du azure-pipelines.ymlfrå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.

Anmärkning

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 pushar en ändring i en gren. Du kan också distribuera programmet till en miljö som utför mer omfattande testning. Men du gör den här distributionen bara när du har en pull request, när du har en versionskandidat, eller när du sammanfogar kod till huvudgrenen .

Mer information finns i Implementera ett kodarbetsflöde i bygg-pipelinen med 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 Dev-fasen.

Ändra azure-pipelines.ymli 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 byggde du och teamet en prototyp för kontinuerlig driftsättning. 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).
Steget Distribuera från proof of concept heter nu Dev.
Dev-steget använder ett villkor som styr systemet att köra steget 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.

Not

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 fasen Dev 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.

Tips

Innan du kör dessa Git-kommandon 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 kompileringen. Spåra bygget medan 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 framgångsrikt.
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å App Service-information sidan.

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

Azure Pipelines registrerar distributionshistoriken. I historiken kan du spåra ändringar i miljön tillbaka till kodåtaganden och arbetsobjekt.

Övning – Flytta upp till Utvecklingssteget

Hämta grenen från GitHub

Flytta upp ändringar i Utvecklingssteget

Feedback