Criar e direcionar um ambiente

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Um ambiente é uma coleção de recursos que você pode direcionar com implantações de um pipeline. Exemplos típicos de nomes de ambiente são Desenvolvimento, Teste, Garantia de qualidade, Preparo e Produção. Um ambiente do Azure DevOps representa um destino lógico em que o pipeline implanta software.

Os ambientes do Azure DevOps não estão disponíveis em pipelines clássicos. Para pipelines clássicos, os grupos de implantação oferecem funcionalidade semelhante.

Os ambientes fornecem os benefícios a seguir.

Benefício	Descrição
Histórico de implantações	Os detalhes do pipeline e da execução são registrados para implantações em um ambiente e seus recursos. No contexto de vários pipelines direcionados ao mesmo ambiente ou recurso, o histórico de implantação de um ambiente é útil para identificar a origem das alterações.
Rastreabilidade de confirmações e itens de trabalho	Exiba trabalhos dentro da execução de pipeline direcionada a um ambiente. Você também pode exibir os commits e os itens de trabalho implantados recentemente no ambiente. A rastreabilidade também permite controlar se uma alteração de código (commit) ou correção de recurso/bug (itens de trabalho) atingiu um ambiente.
Integridade dos recursos de diagnóstico	Valide se o aplicativo está funcionando em seu estado desejado.
Segurança	Proteja ambientes especificando quais usuários e pipelines têm permissão para direcionar um ambiente.

Embora um ambiente seja um agrupamento de recursos, os recursos em si representam destinos de implantação reais. Atualmente, há suporte para os tipos de recurso do Kubernetes e recurso de máquina virtual.

Quando você cria um pipeline YAML e se refere a um ambiente que não existe, o Azure Pipelines cria automaticamente o ambiente quando o usuário que executa a operação é conhecido e as permissões podem ser atribuídas. Quando o Azure Pipelines não tem informações sobre o usuário que está criando o ambiente (exemplo: uma atualização YAML de um editor de código externo), o pipeline falhará se o ambiente ainda não existir.

Pré-requisitos

• Você precisa ter a função de Criador de Ambientes para adicionar um Ambiente.

Criar um ambiente

1. Entre na sua organização: https://dev.azure.com/{yourorganization} e selecione seu projeto.

2. Selecione Pipelines>Ambientes>Criar ambiente.

   

3. Insira informações para o ambiente e selecione Criar. Os recursos depois podem ser adicionados a um ambiente existente.

   

Use um Pipeline para criar e implantar em ambientes também. Para mais informações, confira o guia de instruções.

Dica

Você pode criar um ambiente vazio e referenciá-lo em trabalhos de implantação. Isso permite que você registre o histórico de implantação no ambiente.

Direcionar um ambiente de um trabalho de implantação

Um trabalho de implantação é uma coleção de etapas a serem executadas sequencialmente. Um trabalho de implantação pode ser usado para direcionar um ambiente inteiro (grupo de recursos), conforme mostrado no snippet do YAML a seguir. O pipeline será executado no computador myVM porque o nome do recurso é especificado.

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

Direcionar um recurso específico em um ambiente do trabalho de implantação

Você pode definir o escopo do destino da implantação para um recurso específico dentro do ambiente. Em seguida, você pode registrar o histórico de implantação em um recurso específico dentro do ambiente. As etapas do trabalho de implantação herdam automaticamente os detalhes da conexão de serviço do recurso direcionado pelo trabalho de implantação.

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)
         # value for kubernetesServiceConnection input automatically passed down to task by environment.resource input

Ambiente em detalhes de execução

Todos os ambientes que são direcionados por trabalhos de implantação de uma execução específica de um pipeline podem ser encontrados na guia Ambientes dos detalhes da execução do pipeline.

Se você estiver usando um cluster privado do AKS, a guia Ambientes não estará disponível.

Aprovações

Controle manualmente quando uma fase deve ser executada usando verificações de aprovação. Use verificações de aprovação para controlar implantações em ambientes de produção. As verificações estão disponíveis para o proprietário do recurso para controlar quando uma fase em um pipeline consome um recurso. Como o proprietário de um recurso, como um ambiente, você pode definir as verificações que devem ser satisfeitas antes que uma fase que consome o recurso possa começar.

Damos suporte a verificações manuais de aprovação em ambientes. Para obter mais informações, confira Aprovações.

As funções Criador, Administrador e usuário podem gerenciar aprovações e verificações. A função Leitor não pode gerenciar aprovações e verificações.

Histórico de implantações

A exibição do histórico de implantação em ambientes oferece as seguintes vantagens.

• Exiba trabalhos de todos os pipelines direcionados a um ambiente específico. Por exemplo, dois microsserviços, cada um com o próprio pipeline, estão implantando no mesmo ambiente. A listagem do histórico de implantação ajuda a identificar todos os pipelines que afetam esse ambiente e também ajuda a visualizar a sequência de implantações de cada pipeline.

  

• Faça uma busca detalhada nos detalhes do trabalho para ver a lista de commits e itens de trabalho implantados no ambiente. A lista de commits e itens de trabalho são os novos itens entre implantações. Sua primeira listagem inclui todos os commits e as listagens a seguir incluirão apenas alterações. Se vários commits estiverem vinculados à mesma solicitação de pull, você verá vários resultados nas guias itens de trabalho e alterações.

  

• Se vários itens de trabalho estiverem vinculados à mesma solicitação de pull, você verá vários resultados na guia itens de trabalho.

  

Segurança

Permissões de usuário

Controle quem pode criar, exibir, usar e gerenciar os ambientes com permissões de usuário. Há quatro funções: criador (escopo: todos os ambientes), leitor, usuário e administrador. No painel de permissões de usuário do ambiente específico, você pode definir as permissões herdadas e substituir as funções para cada ambiente.

1. Vá para o Ambiente específico que você deseja autorizar.
2. Selecione >Segurança para exibir as configurações.
3. Selecione Permissões de usuário>+Adicionar>Usuário ou grupo e selecione uma função adequada.

Função	Descrição
Criador	Função global, disponível na opção de segurança do hub de ambientes. Os membros dessa função podem criar o ambiente no projeto. Os colaboradores são adicionados como membros por padrão. Necessário para disparar um pipeline YAML quando o ambiente ainda não existir.
Leitor	Os membros dessa função podem exibir o ambiente.
Usuário	Os membros dessa função podem usar o ambiente ao criar ou editar pipelines YAML.
Administrador	Os membros dessa função podem administrar permissões, criar, gerenciar, exibir e usar ambientes. Para um ambiente específico, seu criador é adicionado como Admininistrator por padrão. Os administradores também podem abrir o acesso a um ambiente para todos os pipelines.

Permissões de pipeline

Use permissões de pipeline para autorizar todos os pipelines selecionados ou para implantação no ambiente.

• Para remover o Acesso aberto no ambiente ou no recurso, selecione Restringir permissão em Permissões de pipeline.
• Para permitir que pipelines específicos implantem em um ambiente ou recurso específico, selecione + e escolha na lista de pipelines.

Próximas etapas

Definir aprovações e verificações

Perguntas frequentes

P: Por que recebo uma mensagem de erro ao tentar criar um ambiente?

R: Se você vir a mensagem "Acesso negado: {Usuário} precisa criar permissões para executar a ação", verifique suas permissões no nível da organização. Acesse Configurações da Organização>Usuários e marque se você tem a função de stakeholder. A função de stakeholder não pode criar ambientes. Altere o nível de acesso e verifique se você pode criar ambientes. Para mais informações, confira Perguntas frequentes sobre gerenciamento de usuários e permissões.

P: Por que estou recebendo o erro "Trabalho XXXX: o Ambiente XXXX não foi encontrado. O ambiente não existe ou não foi autorizado para uso?

R: Estes são alguns dos possíveis motivos da falha:

• Quando você cria um pipeline YAML e se refere a um ambiente que não existe no arquivo YAML, o Azure Pipelines cria automaticamente o ambiente em alguns casos:

  • Você usa o assistente de criação de pipeline YAML na experiência Web do Azure Pipelines e se refere a um ambiente que ainda não foi criado.
  • Atualize o arquivo YAML usando o editor Web do Azure Pipelines e salve o pipeline depois de adicionar uma referência a um ambiente que não existe.

• Nos fluxos a seguir, o Azure Pipelines não tem informações sobre o usuário que está criando o ambiente: você atualize o arquivo YAML usando outro editor de código externo, adiciona uma referência a um ambiente que não existe e, em seguida, faz com que um pipeline de integração seja disparado. Nesse caso, o Azure Pipelines não sabe sobre o usuário. Anteriormente, tratamos desse caso adicionando todos os colaboradores do projeto à função de administrador do ambiente. Qualquer membro do ambiente poderia alterar essas permissões e impedir que outras pessoas acessassem o ambiente.

• Você pode usar variáveis para criar o ambiente ou usar templateContext para transmitir propriedades para modelos. Os parâmetros de runtime não funcionarão ao criar o ambiente porque eles são expandidos em tempo de execução.

• Um usuário com nível de acesso de stakeholder não pode criar o ambiente, pois os stakeholders não têm acesso ao repositório.

Artigos relacionados

• Definir variáveis
• Definir recursos no YAML