Exercício - Crie várias configurações usando modelos

11 minutos

Nos exercícios anteriores, você implementou um pipeline que cria o site Space Game . Você começou com um script que executava cada ação de compilação e mapeava cada ação para sua tarefa de pipeline correspondente. A saída do pipeline é um arquivo .zip que contém o aplicativo Web compilado.

Neste exercício, você usará um modelo para definir tarefas de compilação que podem criar qualquer configuração definida no arquivo de projeto. Os modelos permitem-lhe definir a sua lógica uma vez e, em seguida, reutilizá-la várias vezes. Os modelos combinam o conteúdo de vários arquivos YAML em um único pipeline.

Gorjeta

Esta etapa do módulo é opcional. Se você não quiser saber mais sobre modelos no momento, prossiga para a próxima etapa, Limpar seu ambiente de DevOps do Azure. Para obter mais informações sobre modelos, consulte Tipos de modelo e uso.

Comecemos por fazer check-in com Mara e Amita.

A demonstração

Mara, animada para compartilhar seus resultados, rastreia Amita para mostrar a ela o pipeline de construção.

Amita: Estou impressionado que você tenha feito isso funcionar tão rapidamente! Na verdade, eu estava apenas vindo vê-lo porque recebi um e-mail dizendo que a compilação estava pronta. Obrigado! Vejo que o pipeline cria apenas a configuração Release. Também usamos compilações de depuração para que possamos capturar informações adicionais se o aplicativo falhar. Podemos acrescentar isso?

Mara: Com certeza. Eu esqueci de considerar compilações de depuração quando configurei isso. Que tal sentarmos juntos e adicioná-lo?

Amita: Você me mostrou o arquivo YAML que define as etapas de compilação, mas não tenho certeza se sei como modificá-lo.

Mara: Tudo bem. Você pode assistir enquanto eu digito. Podemos pensar nisso em conjunto.

Como você pode definir ambas as configurações de compilação?

Considere as seguintes tarefas que criam e publicam a configuração Release do projeto Web Space Game . (Não adicione este código ao seu ficheiro azure-pipelines.yml .)

- task: DotNetCoreCLI@2
  displayName: 'Build the project - Release'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration Release'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - Release'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration Release --output $(Build.ArtifactStagingDirectory)/Release'
    zipAfterPublish: true

Para criar a configuração Debug, você pode repetir essas duas tarefas, mas substituir Release por Debug.

Fazer isso lhe daria o resultado que você está procurando, mas o que acontece quando sua compilação se torna mais complexa ou seus requisitos mudam? Você precisaria localizar e alterar manualmente ambas as variações de cada tarefa de compilação. Depois de adicionar os requisitos de compilação adicionais, você também precisará criar duas tarefas, uma para a configuração de depuração e outra para a versão, para atender a esses requisitos.

Uma solução melhor é usar um modelo.

O que são modelos?

Um modelo permite definir tarefas de compilação comuns uma vez e reutilizar essas tarefas várias vezes.

Você chamará um modelo do pipeline pai como uma etapa de compilação. Você pode passar parâmetros para um modelo a partir do pipeline pai.

Mara pode definir tarefas para criar e publicar o aplicativo como um modelo e, em seguida, aplicar esse modelo a cada configuração que ela precisa.

Definir o modelo

Lembre-se de que um modelo permite definir tarefas de compilação comuns uma vez e reutilizá-las várias vezes. Você chama um modelo de seu modelo pai como uma etapa de compilação e passa parâmetros para um modelo do pipeline pai.

Agora você criará um modelo que pode criar qualquer configuração definida no arquivo de projeto.

No console integrado do Visual Studio Code, na raiz do seu projeto, crie um diretório de modelos .
```
mkdir templates
```
Na prática, você pode colocar um arquivo de modelo em qualquer local. Você não precisa colocá-los no diretório de modelos .
No Visual Studio Code, selecione Arquivo > Novo Arquivo. Em seguida, para salvar o arquivo em branco como build.yml no diretório de modelos do projeto, selecione Salvar arquivo>. Um exemplo seria ~/mslearn-tailspin-spacegame-web/templates.

Importante

Como antes, no Windows, na lista Salvar como tipo , selecione YAML.

No Visual Studio Code, adicione este código a build.yml:

parameters:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  displayName: 'Build the project - ${{ parameters.buildConfiguration }}'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration ${{ parameters.buildConfiguration }}'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - ${{ parameters.buildConfiguration }}'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration ${{ parameters.buildConfiguration }} --output $(Build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
    zipAfterPublish: true

Essas tarefas se parecem com as que você definiu anteriormente para criar e publicar o aplicativo; Mas em um modelo, você trabalha com parâmetros de entrada de forma diferente do que trabalha com variáveis normais. Aqui estão duas diferenças:

Em um arquivo de modelo, use a parameters seção em vez de variables definir entradas.
Em um arquivo de modelo, use ${{ }} sintaxe em vez de ler o valor de $() um parâmetro. Ao ler o valor de um parâmetro, você incluirá a parameters seção em seu nome. Por exemplo, ${{ parameters.buildConfiguration }}.

Chamar o modelo do pipeline

Agora você chamará o modelo que acabou de criar a partir do pipeline. Você fará isso uma vez para a configuração de depuração e, em seguida, repetirá o processo para a configuração de versão.

No Visual Studio Code, modifique azure-pipelines.yml como você vê aqui:

trigger:
- '*'

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: 'Release'
  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'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Debug'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Release'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

trigger:
- '*'

pool:
  name: 'Default' #replace if needed with name of your agent pool

variables:
  buildConfiguration: 'Release'
  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'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Debug'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Release'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Esse arquivo se parece com o original, exceto que ele substitui as tarefas de compilação e publicação por chamadas para o modelo que executa as mesmas tarefas.

Você verá que o modelo é chamado uma vez para cada configuração. Para passar o nome da configuração para o modelo, cada template tarefa usa o parameters argumento.

Executar o pipeline

Agora você enviará suas alterações para o GitHub e verá o pipeline ser executado.

A partir do terminal integrado, adicione azure-pipelines.yml e modelos/build.yml ao índice, confirme as alterações e envie as alterações para o GitHub.
```
git add azure-pipelines.yml templates/build.yml
git commit -m "Support build configurations"
git push origin build-pipeline
```
A partir dos Pipelines do Azure, rastreie a compilação através de cada uma das etapas como fez anteriormente.

À medida que o pipeline é executado, você verá que o processo expande as tarefas dentro do modelo. As tarefas que compilam e publicam o projeto são executadas duas vezes, uma para cada configuração de compilação.
Quando a compilação for concluída, volte para a página de resumo e selecione o artefato publicado como fazia antes. Expanda a pasta suspensa.

Você verá que o pipeline produz um arquivo .zip para a configuração Debug e a configuração Release.

Mesclar a ramificação na principal

Neste ponto, você tem um pipeline de construção de trabalho que realiza tudo o que Mara precisa agora.

Na prática, você enviaria uma solicitação pull que mescla sua build-pipeline filial na main filial.

Vamos pular essa etapa por enquanto. No próximo módulo, você aprenderá algumas maneiras de colaborar com sua equipe no GitHub, incluindo como enviar, revisar e mesclar solicitações pull.