Esercizio - Alza di livello la fase di sviluppo

8 minuti

Il team ha un piano ed è pronto per iniziare a implementare la pipeline di versione. Il progetto Azure DevOps è configurato e le istanze del servizio app Azure sono pronte per ricevere gli artefatti di compilazione.

A questo punto, tenere presente che la pipeline del team ha solo due fasi. La prima fase produce l'artefatto di compilazione. La seconda fase distribuisce l'app Web Space Game in servizio app. In questo caso, si seguiranno Andy e Mara mentre modificano la pipeline. Verranno distribuiti nell'ambiente servizio app che corrisponde alla fase sviluppo.

La fase di sviluppo è simile alla fase di distribuzione creata nel modulo Creare una pipeline di versione in Azure Pipelines . È stato usato un trigger di integrazione continua per avviare il processo di compilazione. In questa sezione si eseguirà la stessa operazione.

Recuperare il ramo da GitHub

Qui si recupera il release ramo da GitHub. È anche possibile eseguire il check-out o passare al ramo .

Questo ramo funge da ramo di rilascio . Contiene il progetto Space Game usato nei moduli precedenti. Contiene anche una configurazione di Azure Pipelines da cui iniziare.

Per recuperare e passare al ramo:

Aprire il terminale integrato in Visual Studio Code.
Per recuperare un ramo denominato release dal repository Microsoft e passare a tale ramo, eseguire i comandi seguenti git .
```
git fetch upstream release
git checkout -B release upstream/release
```
Il formato di questi comandi consente di ottenere il codice di avvio dal repository GitHub di Microsoft, noto come upstream. A breve, si eseguirà il push di questo ramo nel repository GitHub, noto come origin.
Come passaggio facoltativo, da Visual Studio Code aprire azure-pipelines.yml. Acquisire familiarità con la configurazione iniziale.

La configurazione è simile a quella di base creata nel modulo Creare una pipeline di versione con Azure Pipelines . Compila solo la configurazione della versione dell'app. Ai fini dell'apprendimento, questa configurazione non esegue i controlli di qualità o sicurezza configurati nei moduli precedenti.

Nota

Una configurazione più affidabile potrebbe specificare i rami che partecipano al processo di compilazione. Ad esempio, per verificare la qualità del codice, è possibile eseguire unit test ogni volta che si esegue il push di una modifica in qualsiasi ramo. È anche possibile distribuire l'applicazione in un ambiente che esegue test più completi. Questa distribuzione viene tuttavia usata solo quando si ha una richiesta pull, quando si ha una versione finale candidata o quando si esegue il merge del codice in main.

Per altre informazioni, vedere Implementare un flusso di lavoro di codice nella pipeline di compilazione usando Git e GitHub e i trigger della pipeline di compilazione.

Alzare di livello le modifiche alla fase di sviluppo

In questo caso, si modifica la configurazione della pipeline per alzare di livello la compilazione alla fase di sviluppo .

In Visual Studio Code modificare 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'

Questa configurazione è simile a quella compilata nel modulo precedente. Qui, l'utente e il team hanno creato un modello di verifica per la distribuzione continua. Si notino tuttavia queste differenze, evidenziate nell'esempio di codice precedente:

Questa configurazione definisce le variabili all'inizio del file. Le variabili vengono usate in tutta la pipeline. Definiscono la configurazione da compilare (Release). Definiscono anche il nome del ramo di rilascio (release).
La fase Distribuisci dal modello di verifica è ora denominata Dev.
La fase Sviluppo usa una condizione che indirizza il sistema a eseguire la fase solo quando la fase precedente ha esito positivo e il ramo corrente è release. Questa configurazione garantisce che le funzionalità di rilascio vengano distribuite solo nell'ambiente di sviluppo .
Il passaggio di distribuzione usa la WebAppNameDev variabile per la distribuzione nell'istanza di servizio app associata all'ambiente di sviluppo.

Nota

In pratica, è possibile eseguire la distribuzione da un altro ramo, ad esempio main. È possibile includere la logica che consente la promozione delle modifiche alla fase di sviluppo da più rami, ad esempio release e main.

Dal terminale integrato aggiungere azure-pipelines.yml all'indice. Eseguire il commit della modifica ed eseguirne il push in GitHub.

Suggerimento

Prima di eseguire questi comandi Git, salvare azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev stage"
git push origin release
```
In Azure Pipelines passare alla compilazione. Durante l'esecuzione, tracciare la compilazione.
Al termine della compilazione, per tornare alla pagina di riepilogo, selezionare il pulsante Indietro.

Si noterà che la distribuzione è stata completata correttamente.
Da un Web browser passare all'URL associato all'istanza di servizio app per l'ambiente di sviluppo.

Se la scheda del browser è ancora aperta, aggiornare la pagina. Se non si ricorda l'URL, trovarlo nella portale di Azure, nella pagina dei dettagli servizio app.

Si noterà che il sito Web Space Game viene distribuito in servizio app ed è in esecuzione.
Come passaggio facoltativo, in Azure Pipelines selezionare Ambienti. Selezionare quindi l'ambiente di sviluppo .

Azure Pipelines registra la cronologia di distribuzione. Nella cronologia è possibile tracciare le modifiche dell'ambiente ai commit del codice e agli elementi di lavoro.

Esercizio - Alza di livello la fase di sviluppo

Recuperare il ramo da GitHub

Alzare di livello le modifiche alla fase di sviluppo

Commenti e suggerimenti