Recursos em pipelines YAML

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Este artigo discute recursos para pipelines YAML. Um recurso é qualquer coisa usada por um pipeline que existe fora do pipeline. Depois de definir um recurso, você pode consumi-lo em qualquer lugar do pipeline.

Os recursos fornecem rastreabilidade total para os serviços que seu pipeline usa, incluindo a versão, artefatos, confirmações associadas e itens de trabalho. Você pode automatizar totalmente seus fluxos de trabalho de DevOps inscrevendo-se para acionar eventos em seus recursos.

Esquema de recursos

Os recursos no YAML representam origens de pipelines, compilações, repositórios, contentores, pacotes e webhooks. Para obter informações completas sobre o esquema, consulte a definição de recursos na referência de esquema YAML para Pipelines do Azure.

Quando um recurso aciona um pipeline, as seguintes variáveis são definidas:

resources.triggeringAlias
resources.triggeringCategory

A variável Build.Reason deve ser ResourceTrigger para que esses valores sejam definidos. Os valores estarão vazios se um recurso não acionar a execução do pipeline.

Definição de recursos de pipelines

Se você tiver um pipeline que produz artefatos, poderá consumi-los definindo um pipelines recurso. Somente o Azure Pipelines pode usar o pipelines recurso. Você pode definir gatilhos para seus fluxos de trabalho de implantação contínua (CD) em um recurso de pipeline.

Em sua definição de recurso, pipeline é um valor exclusivo que você pode usar para fazer referência ao recurso de pipeline posteriormente em seu pipeline. O source é o nome do pipeline que produziu o artefato do pipeline. Para obter informações completas sobre o esquema, consulte a definição resources.pipelines.pipeline.

Você usa o rótulo definido por pipeline para fazer referência ao recurso de pipeline de outras partes do pipeline, como ao usar variáveis de recurso de pipeline ou baixar artefatos. Para obter uma maneira alternativa de baixar artefatos de pipeline, consulte Baixar artefatos.

Exemplo de definições de recursos de pipeline

O exemplo a seguir consome artefatos de um pipeline dentro do mesmo projeto.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Para consumir um pipeline de outro projeto, inclua o nome do projeto e o nome da fonte. O exemplo a seguir usa branch para resolver a versão padrão quando o pipeline é acionado manualmente ou agendado. A entrada de ramificação não pode ter curingas.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

O exemplo a seguir mostra um recurso de pipeline com um gatilho simples.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger: true

O exemplo a seguir mostra um recurso trigger de pipeline com condições de ramificação.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

O exemplo a seguir usa stages filtros para avaliar condições de gatilho para pipelines de CD. Os estágios usam o AND operador. Após a conclusão bem-sucedida de todos os estágios fornecidos, o pipeline de CD é acionado.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

O exemplo a seguir usa tags filtros para avaliação de versão padrão e para gatilhos. As tags usam o AND operador.

Os tags são definidos no pipeline de integração contínua (CI) ou CD. Essas tags diferem das tags definidas nas ramificações no repositório Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

Avaliação da versão do artefato de pipelines

A versão do artefato do pipeline de recursos depende de como o pipeline é acionado.

Gatilho manual ou programado

Se a execução do pipeline for acionada ou agendada manualmente, os valores das propriedades , branche definirão tags a versão do versionartefato. A branch entrada não pode ter curingas. As tags propriedades usam o AND operador.

A definição de recurso a seguir pipeline usa as branch propriedades e tags para avaliar a versão padrão quando o pipeline é acionado manualmente ou agendado. Quando você aciona manualmente o pipeline para ser executado, a versão dos artefatos do MyCIAlias pipeline é a compilação mais recente feita na main ramificação que tem as Production tags e PrepProduction .

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Gatilho de conclusão do pipeline de recursos

Quando um pipeline é acionado porque um de seus pipelines de recursos é concluído, a versão dos artefatos é a versão do pipeline de acionamento. Os valores das versionpropriedades , branche são tags ignorados.

O pipeline a seguir é executado sempre que o pipeline de SmartHotel-CI recursos:

• Funciona em uma das releases filiais ou na main filial
• Está marcado com ambos e VerifiedSigned
• Conclui as Production etapas e PreProduction

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction
      

Download do artefato de pipeline

A download etapa baixa artefatos associados à execução atual ou a outro recurso de pipeline.

Todos os artefatos do pipeline atual e todos os seus pipeline recursos são baixados automaticamente e disponibilizados no início de cada trabalho de implantação. Você pode substituir esse comportamento definindo download como none, ou especificando outro identificador de recurso de pipeline.

Os artefatos de trabalho regulares não são baixados automaticamente. Use download explicitamente quando necessário.

Os artefatos do pipeline recurso são baixados para o $(PIPELINE. WORKSPACE)/<pasta pipeline-identifier>/<artifact-identifier> . Para obter mais informações, consulte Publicar e baixar artefatos de pipeline.

A propriedade opcional especifica nomes de artifact artefatos. Se não for especificado, todos os artefatos disponíveis serão baixados. A propriedade opcional patterns define padrões que representam arquivos a serem incluídos. Para obter informações completas sobre o esquema, consulte a definição steps.download.

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Cria definição de recursos

Se você tiver um sistema de compilação de CI externo que produz artefatos, poderá consumir artefatos com builds recursos. Um build recurso pode ser de qualquer sistema de CI externo como Jenkins, TeamCity ou CircleCI.

A builds categoria é extensível. Você pode escrever uma extensão para consumir artefatos do seu serviço de compilação e introduzir um novo tipo de serviço como parte do builds.

build Na definição, version o padrão é a compilação bem-sucedida mais recente. O trigger não está habilitado por padrão e deve ser definido explicitamente. Para obter informações completas sobre o esquema, consulte a definição resources.builds.build.

No exemplo a seguir, Jenkins é o recurso type.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

A tarefa downloadBuild

Os build artefatos de recurso não são baixados automaticamente em seus jobs/deploy-jobs. Para consumir artefatos do build recurso como parte de seus trabalhos, você precisa adicionar explicitamente a downloadBuild tarefa. Você pode personalizar o comportamento de download para cada implantação ou trabalho.

Esta tarefa é automaticamente resolvida para a tarefa de download correspondente para o tipo de recurso que o tempo de build execução define. Os artefatos do build recurso são baixados para o $(PIPELINE. WORKSPACE)/<build-identifier>/ pasta.

downloadBuild Na definição, você especifica o recurso do qual baixar artefatos. A propriedade opcional artifact especifica artefatos para download. Se não for especificado, todos os artefatos associados ao recurso serão baixados.

A propriedade opcional patterns define um caminho de minicorrespondência ou uma lista de caminhos de minicorrespondência para download. Se estiver em branco, todo o artefato será baixado. Por exemplo, o trecho a seguir baixa apenas os arquivos *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Para obter informações completas sobre o esquema, consulte a definição steps.downloadBuild.

Definição de recursos do repositório

A repository palavra-chave permite especificar um repositório externo. Você pode usar esse recurso se seu pipeline tiver modelos em outro repositório ou se quiser usar o check-out multi-repo com um repositório que exija uma conexão de serviço. Você deve informar o sistema sobre esses repositórios.

Por exemplo:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Para obter informações completas sobre o esquema, consulte a definição resources.repositories.repository.

Tipos de recursos do repositório

O Azure Pipelines dá suporte aos seguintes valores para o tipo de repositório: git, github, githubenterprisee bitbucket.

• O git tipo refere-se aos repositórios Git do Azure Repos.
• Os repositórios do GitHub Enterprise exigem uma conexão de serviço do GitHub Enterprise para autorização.
• Os repositórios Bitbucket Cloud requerem uma conexão de serviço Bitbucket Cloud para autorização.

Variáveis de recursos do repositório

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

Palavra-chave de check-out para repositórios

Os repositórios do repository recurso não são sincronizados automaticamente em seus trabalhos. Use a checkout palavra-chave para buscar um repositório definido como parte do repository recurso. Para obter informações completas sobre o esquema, consulte a definição steps.checkout.

Para obter mais informações, consulte Verificar vários repositórios em seu pipeline.

Definição de recursos de contêineres

Se você precisar consumir imagens de contêiner como parte de seus pipelines de CI/CD, poderá usar containers recursos. Um container recurso pode ser um registro do Docker público ou privado ou uma instância do Registro de Contêiner do Azure.

Você pode consumir uma imagem genérica de recurso de contêiner como parte de seu trabalho ou usar o recurso para trabalhos de contêiner. Se o pipeline exigir o suporte de um ou mais serviços, você precisará criar e conectar-se a contêineres de serviço. Você pode usar volumes para compartilhar dados entre serviços.

Se você precisar consumir imagens de um registro do Docker como parte do pipeline, poderá definir um recurso de contêiner genérico. Nenhuma type palavra-chave é necessária. Por exemplo:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp 

Para obter informações completas sobre o esquema, consulte a definição resources.containers.container.

Tipo de recurso do Registro de Contêiner do Azure

Para consumir suas imagens do Registro de Contêiner do Azure, você pode usar o tipo acrde recurso de contêiner de primeira classe . Você pode usar esse tipo de recurso como parte de seus trabalhos e para habilitar gatilhos automáticos de pipeline.

Você precisa de permissões de Colaborador ou Proprietário para o Registro de Contêiner do Azure para usar gatilhos de pipeline automáticos. Para obter mais informações, consulte Funções e permissões do Registro de Contêiner do Azure.

Para usar o acr tipo de recurso, você deve especificar o azureSubscription, resourceGroupe repository valores para seu registro de contêiner do Azure. Por exemplo:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production* 

Variáveis de recurso de contêiner

Depois de definir um contêiner como um recurso, os metadados da imagem do contêiner passam para o pipeline como variáveis. Informações como imagem, registro e detalhes de conexão estão acessíveis em todos os trabalhos usados em suas tarefas de implantação de contêiner.

As variáveis de recurso de contêiner funcionam com o Docker e o Registro de Contêiner do Azure. Não é possível usar variáveis de recurso de contêiner para contêineres de imagem locais. A location variável se aplica somente ao acr tipo de recursos de contêiner.

O exemplo a seguir tem uma conexão de serviço do Azure Resource Manager chamada arm-connection. Para obter mais informações, consulte Registros, repositórios e imagens de contêiner do Azure.

resources:
  containers:
  - container: mycontainer
    type: ACR
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

steps:  
- script: echo ${{ parameters.WebHook.resource.message.title }}

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Seletor manual de versão para recursos

Quando você aciona manualmente um pipeline YAML de CD, o Azure Pipelines avalia automaticamente as versões padrão para os recursos definidos no pipeline, com base nas entradas fornecidas. No entanto, o Azure Pipelines considera apenas execuções de CI concluídas com êxito ao avaliar a versão padrão para gatilhos agendados ou se você não escolher manualmente uma versão.

Você pode usar o seletor de versão de recursos para escolher manualmente uma versão diferente ao criar uma execução. O seletor de versão de recursos é suportado para recursos de pipeline, compilação, repositório, contêiner e pacote.

Para recursos de pipeline, você pode ver todas as execuções disponíveis em todas as ramificações, pesquisá-las com base no número do pipeline ou ramificação e escolher uma execução bem-sucedida, com falha ou em andamento. Essa flexibilidade garante que você possa executar seu pipeline de CD se tiver certeza de que uma execução produziu todos os artefatos necessários. Você não precisa esperar que uma execução de CI seja concluída ou executá-la novamente devido a uma falha de estágio não relacionada.

Para usar o seletor de versão de recurso, no painel Executar pipeline , selecione Recursos, selecione um recurso e escolha uma versão específica na lista de versões disponíveis.

Para recursos em que você não pode buscar versões disponíveis, como pacotes do GitHub, o seletor de versão fornece um campo de texto para que você possa inserir a versão para a execução a ser selecionada.

Autorização de recursos em pipelines YAML

Os recursos devem ser autorizados antes de poderem ser usados em gasodutos. Os proprietários de recursos controlam os usuários e pipelines que podem acessar seus recursos. Há várias maneiras de autorizar um pipeline YAML para usar recursos.

• Use a experiência de administração de recursos para autorizar todos os pipelines a acessar o recurso. Por exemplo, grupos de variáveis e arquivos seguros são gerenciados na página Biblioteca em Pipelines, e pools de agentes e conexões de serviço são gerenciados nas configurações do Project. Essa autorização é conveniente se você não precisar restringir o acesso a recursos, como para recursos de teste.

• Quando você cria um pipeline, todos os recursos referenciados no arquivo YAML são automaticamente autorizados para uso pelo pipeline se você tiver a função Usuário para esses recursos.

• Se você adicionar um recurso a um arquivo YAML e a compilação falhar com um erro como Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., você verá uma opção para autorizar os recursos na compilação com falha.

  Se você for um membro da função Usuário do recurso, poderá selecionar essa opção e autorizar o recurso na compilação com falha. Depois que o recurso for autorizado, você poderá iniciar uma nova compilação.

• Verifique se as funções de segurança do pool de agentes para seu projeto estão corretas.

Verificações de aprovação de recursos

Você pode usar verificações de aprovação e modelos para controlar manualmente quando um recurso é executado. Com a verificação de aprovação de modelo necessária, você pode exigir que qualquer pipeline usando um recurso ou ambiente se estenda a partir de um modelo YAML específico.

Definir uma aprovação de modelo necessária garante que seu recurso seja usado apenas sob condições específicas e aumenta a segurança. Para saber mais sobre como melhorar a segurança do pipeline com modelos, consulte Usar modelos para segurança.

Rastreabilidade

O Azure Pipelines fornece rastreabilidade total para qualquer recurso consumido em um pipeline ou nível de trabalho de implantação.

Rastreabilidade de oleodutos

O Azure Pipelines mostra as seguintes informações para cada execução de pipeline:

• Se um recurso acionou o pipeline, o recurso que disparou o pipeline.
• A versão do recurso e os artefatos consumidos.
• Confirmações associadas a cada recurso.
• Itens de trabalho associados a cada recurso.

Rastreabilidade de ambiente

Sempre que um pipeline é implantado em um ambiente, você pode ver uma lista de recursos que são consumidos. A exibição inclui recursos consumidos como parte dos trabalhos de implantação e suas confirmações e itens de trabalho associados.

Informações de pipelines de CD associados em pipelines de CI

Para fornecer rastreabilidade de ponta a ponta, você pode rastrear quais pipelines de CD consomem um pipeline de CI específico por meio do pipelines recurso. Se outros pipelines consumirem seu pipeline de CI, você verá uma guia Pipelines associados na visualização Executar . A exibição mostra todas as execuções do pipeline YAML do CD que consumiram seu pipeline de CI e os artefatos dele.

Problemas de gatilho de recursos

Os gatilhos de recursos podem falhar na execução porque:

• A origem da conexão de serviço fornecida é inválida, há erros de sintaxe no gatilho ou o gatilho não está configurado.
• As condições de gatilho não são correspondidas.

Para ver por que os gatilhos de pipeline não foram executados, selecione o item de menu Problemas de gatilho na página de definição de pipeline. Problemas de gatilho estão disponíveis apenas para recursos que não são do repositório.

Na página Problemas do gatilho , as mensagens de erro e aviso descrevem por que o gatilho falhou.

FAQ

Quando devo usar os recursos de pipelines, o atalho de download ou a tarefa Baixar artefatos de pipeline?

Usar um pipelines recurso é uma maneira de consumir artefatos de um pipeline de CI e também configurar gatilhos automatizados. Um recurso oferece visibilidade total do processo, exibindo a versão consumida, artefatos, confirmações e itens de trabalho. Quando você define um recurso de pipeline, os artefatos associados são baixados automaticamente em trabalhos de implantação.

Você pode usar o download atalho para baixar os artefatos em trabalhos de compilação ou para substituir o comportamento de download em trabalhos de implantação. Para obter mais informações, consulte a definição steps.download.

A tarefa Download Pipeline Artifacts não fornece rastreabilidade ou gatilhos, mas às vezes faz sentido usar essa tarefa diretamente. Por exemplo, você pode ter uma tarefa de script armazenada em um modelo diferente que exija que artefatos de uma compilação sejam baixados. Ou, talvez você não queira adicionar um recurso de pipeline a um modelo. Para evitar dependências, você pode usar a tarefa Baixar Artefatos de Pipeline para passar todas as informações de compilação para uma tarefa.

Como posso acionar uma execução de pipeline quando minha imagem do Docker Hub é atualizada?

O gatilho de recurso de contêiner não está disponível para pipelines do Docker Hub for YAML, portanto, você precisa configurar um pipeline de liberação clássico.

1. Crie uma nova conexão de serviço do Docker Hub.
2. Crie um pipeline de versão clássico e adicione um artefato do Docker Hub. Defina sua conexão de serviço e selecione o namespace, o repositório, a versão e o alias de origem.
3. Selecione o gatilho e alterne o gatilho de implantação contínua para Ativar. Cada push do Docker que ocorre no repositório selecionado cria uma versão.
4. Crie um novo estágio e trabalho. Adicione duas tarefas, login no Docker e Bash.
   • A tarefa do Docker tem a login ação e faz login no Docker Hub.
   • A tarefa Bash é executada docker pull <hub-user>/<repo-name>[:<tag>].

Como posso validar e solucionar problemas do meu webhook?

1. Crie uma conexão de serviço.

2. Faça referência à sua conexão de serviço e nomeie webhooks seu webhook na seção.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. Execute os seus pipelines. O webhook é criado no Azure como uma tarefa distribuída para sua organização.

4. Execute uma chamada de POST API com JSON válido no corpo para https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Se você receber uma resposta de código de status 200, seu webhook estará pronto para consumo pelo seu pipeline.

Se você receber uma resposta de código de status 500 com o erro Cannot find webhook for the given webHookId ..., seu código pode estar em uma ramificação que não é sua ramificação padrão. Para resolver este problema:

1. Selecione Editar na página do pipeline.
2. No menu Mais ações , selecione Triggers.
3. Selecione a guia YAML e, em seguida, selecione Obter fontes.
4. Em Ramificação padrão para compilações manuais e agendadas, atualize sua ramificação de recurso.
5. Selecione Salvar fila & .
6. Depois que esse pipeline for executado com êxito, execute uma POST chamada de API com JSON válido no corpo para https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Agora você deve receber uma resposta de código de status 200.

Conteúdos relacionados

• Sobre recursos para o Azure Pipelines
• Definir variáveis
• Adicionar e usar grupos de variáveis
• Criar e selecionar um ambiente
• Usar o editor de pipeline YAML
• Referência do esquema YAML