Entender os ambientes
Os pipelines de implantação permitem que você automatize as etapas do processo de implantação. Muitas vezes, você precisa executar as etapas em vários ambientes separados. Em sua empresa de brinquedos, você quer examinar as alterações ao código antes de implantar as alterações no ambiente de produção.
Nesta unidade, você aprenderá como os ambientes no Azure Pipelines ajudam você a dar suporte ao seu fluxo de trabalho.
Por que você tem vários ambientes?
Os processos de implantação fazem alterações aos recursos do Azure, incluindo os recursos em uso. A alteração de recursos envolve algum risco, pois as alterações implantadas podem não se comportar conforme o esperado. Você pode até mesmo descobrir que as alterações causam ruptura na configuração atual.
Para minimizar o risco de problemas, é uma boa prática testar as alterações com segurança antes de implantá-las no ambiente de produção. Por exemplo, você pode implantar as alterações em um ambiente de não produção.
Muitas organizações configuram vários ambientes que não são de produção, nos quais implantam progressivamente as alterações antes de liberá-las para produção. Cada ambiente não de produção atende a uma finalidade específica e, muitas vezes, tem portas de qualidade específicas que devem ser atendidas para prosseguir para o ambiente seguinte. Se algo der errado, como uma falha de teste, a implantação será interrompida. À medida que sua implantação passa pelos ambientes, sua confiança nas alterações aumenta.
Os ambientes comuns incluem:
Desenvolvimento: um ambiente de desenvolvimento normalmente é usado por desenvolvedores para experimentar suas alterações e iterar rapidamente o trabalho.
Ambientes de desenvolvimento geralmente têm controles mínimos para que os membros da equipe possam experimentar as ideias facilmente. Você pode usar um ambiente de desenvolvimento para testar uma determinada definição de configuração em um recurso ou para ver como você pode configurar um novo site com um banco de dados back-end de maneira segura. Muitas dessas alterações e avaliações podem não avançar no processo de implantação, pois as ideias que não têm sucesso são eliminadas.
Em algumas equipes, você pode inclusive configurar um ambiente de desenvolvimento separado para cada membro da equipe, de modo que eles não fiquem no caminho uns dos outros enquanto trabalham em novos recursos.
Os ambientes de desenvolvimento às vezes também são chamados de ambientes de área restrita.
Teste: um ambiente de teste foi projetado para executar testes manuais ou automatizados em relação às suas alterações.
Ambientes de teste podem ser usados em um processo de integração contínua. Depois de implantar uma alteração em um ambiente de teste, os testes automatizados podem ser executados nele. Se todos os testes automatizados forem aprovados, será seguro mesclar a alteração na ramificação principal do projeto. Os testes automatizados geralmente verificam a funcionalidade do sistema principal, juntamente com itens como violações de política nos recursos implantados recentemente.
Você também pode criar ambientes de teste dedicados para tipos específicos de teste, como teste de desempenho e segurança.
Integração: um ambiente de integração pode ajudá-lo a testar todos os pontos de integração com outros sistemas.
Você pode simular transações de ponta a ponta em um ambiente de integração. Esses testes geralmente são executados de modo automático, porém, muitas organizações também executam testes manuais nesse ambiente.
Às vezes, os ambientes de integração também são chamados de ambientes SIT (teste de integração do sistema).
Teste de aceitação do usuário: um ambiente UAT (teste de aceitação do usuário) é usado para validação manual, geralmente por stakeholders de negócios, em vez de desenvolvedores. Na validação manual, alguém passa pela solução e verifica se ela se comporta conforme o esperado e cumpre os requisitos de negócios necessários. Em seguida, essa pessoa aprova as alterações para que a implantação possa continuar.
Pré-produção: um ambiente de pré-produção geralmente é um espelho do ambiente de produção, com as mesmas SKUs de recurso e configuração. Ele é usado como uma verificação final para ver como a implantação de produção se comportará durante e depois que a alteração for aplicada. Ele também pode ser usado para verificar se você deve esperar algum tempo de inatividade durante a implantação de produção.
Ambientes de pré-produção às vezes também são chamados de ambientes de preparo.
Produção: o ambiente de produção é o que os usuários finais do aplicativo usam. É o ambiente ativo que você deseja proteger e manter em funcionamento o máximo possível.
Em algumas organizações, você pode ter vários ambientes de produção. Por exemplo, você pode ter ambientes de produção em diferentes regiões geográficas ou atender a diferentes grupos de clientes.
Demonstração: sua equipe também pode criar ambientes de demo (demonstração) para mostrar o aplicativo aos usuários finais, para uso no treinamento ou para que as equipes de vendas mostrem determinadas funcionalidades para clientes potenciais. Você pode até mesmo ter vários ambientes de demonstração que atendem a finalidades diferentes. Um ambiente de demonstração geralmente é uma réplica reduzida do seu ambiente de produção contendo dados falsos do cliente.
Ambientes em sua organização
Você pode ver variações desses ambientes. Algumas organizações usam apenas alguns ambientes, enquanto outras usam muito. O número e o tipo de ambientes que você usa dependem da solução que você está implantando, do tamanho da equipe que está criando a solução e da importância da carga de trabalho.
Às vezes, um só ambiente assume a função de vários dos ambientes listados anteriormente. Outras vezes, você pode ter um pipeline complexo que implanta em vários ambientes, alguns em paralelo e outros em sequência. Algumas organizações até mesmo excluem ou desprovisionam automaticamente ambientes quando não são mais usados e depois reimplantam-nos quando são necessários no futuro.
Independentemente da escolha de lista de ambientes da sua organização, a meta é melhorar sua confiança em uma alteração à medida que ela avança no pipeline de implantação. Quando uma alteração não atender aos seus requisitos de qualidade, você poderá interromper a implantação dessa alteração em qualquer ambiente subsequente na cadeia.
Em sua empresa de brinquedos, você decide começar com um conjunto básico de ambientes para seu site. Além do ambiente de produção, você criará um ambiente de não produção chamado Teste:
Você atualizará o pipeline para implantar seu código Bicep no ambiente de teste e executará alguns testes básicos nele. Se esse esforço for bem-sucedido, o código será implantado em seu ambiente de produção.
Ambientes de pipeline
O Azure Pipelines também tem o conceito de um ambiente. Você cria um ambiente do Azure Pipelines para representar o ambiente que você tem no Azure. Ao definir seu pipeline em um arquivo YAML, você vincula seus trabalhos de implantação a um ambiente específico. Usando ambientes, você obterá alguns outros recursos em seu pipeline.
Verificações e aprovações
Um ambiente no Azure DevOps pode ter verificações e aprovações configuradas. Sempre que o ambiente é usado em um trabalho em seu pipeline, o Azure DevOps analisa se essas verificações e aprovações são bem-sucedidas antes do início da execução do trabalho.
Por exemplo, você pode configurar aprovações manuais em seu ambiente de produção. Antes do início de uma implantação de produção, o aprovador designado recebe uma notificação por email. Essa pessoa pode verificar manualmente se suas políticas e procedimentos foram atendidos antes do início da implantação. Por exemplo, o aprovador pode verificar se tudo está funcionando conforme o esperado no ambiente de pré-produção antes de aprovar a implantação.
Além disso, você pode executar uma verificação automatizada para examinar os logs e as taxas de erro em seu ambiente de pré-produção após sua última implantação. Se a verificação confirmar que o número de erros não aumentou substancialmente, ela permitirá que a implantação continue.
Histórico de implantações
O Azure Pipelines rastreia o histórico das implantações em um ambiente. Esse histórico oferece um modo fácil de acompanhar o que acontece no ambiente ao longo do tempo. Ele permite até mesmo rastrear uma implantação para uma solicitação de recurso específica em seus itens de trabalho do Azure Boards ou para uma commit em seu repositório. Esse recurso poderá ser útil se você tiver um problema com uma implantação e precisar identificar a alteração que levou ao problema.
Segurança
Você pode aplicar outros controles de segurança aos ambientes. Você pode restringir os pipelines que têm permissão para usar um ambiente específico. Ou evite que alguém crie acidentalmente um pipeline secundário que interaja com seu ambiente de produção.
Você também pode aplicar permissões de usuário para controlar os usuários que podem gerenciar ambientes. Permissões específicas podem permitir que os usuários criem ambientes, modifiquem ambientes e vejam ambientes e o histórico de implantações para eles.
Observação
Quando o pipeline se refere a um ambiente que ainda não existe, o Azure Pipelines o cria automaticamente para você. Esse recurso pode afetar a segurança do projeto do Azure DevOps, pois você obterá automaticamente permissões administrativas para o ambiente. É melhor criar um ambiente por meio da interface da Web Azure DevOps para que você tenha controle total sobre sua segurança e não receba acidentalmente permissões de que não precisa.
Vincular um trabalho de implantação a um ambiente
Na definição do pipeline de implantação, você cria uma propriedade deployment para especificar um trabalho de implantação e especifica o nome do ambiente no qual o trabalho é implantado:
- stage: DeployTest
displayName: Deploy (Test Environment)
jobs:
- deployment: DeployWebsite
environment: Test
strategy:
runOnce:
deploy:
steps:
- checkout: self
No exemplo, o trabalho nomeado DeployWebsite está vinculado ao ambiente Test.
Dica
Os trabalhos também têm outras propriedades, incluindo a estratégia de implantação, que estão além do escopo deste módulo. Há um link para mais informações na unidade de resumo.
Ambientes e conexões de serviço
Ao usar vários ambientes, você deve tornar cada ambiente independente dos outros. Por exemplo, o site do ambiente de desenvolvimento não deve ser capaz de acessar um banco de dados em seu ambiente de produção.
O mesmo princípio também se aplica ao pipeline de implantação. A conexão de serviço que você usa para implantar em seu ambiente de desenvolvimento não deve ser capaz de acessar seu ambiente de produção. Seguir esse princípio adiciona outra camada de proteção para garantir que suas implantações de não produção não afetem seu ambiente de produção.
Você deve criar conexões de serviço separadas para cada ambiente. Cada conexão de serviço deve usar a própria entidade de serviço dedicada, com permissões específicas para implantar apenas a assinatura e o grupo de recursos usados por esse ambiente:
Importante
Use uma entidade de serviço e uma conexão de serviço separadas para cada ambiente em que você planeja implantar. Conceda à entidade de serviço as permissões mínimas de que ela precisa para implantar em seu ambiente e nenhuma outra.
Também é uma boa ideia separar seus ambientes no Azure. No mínimo, você deve criar um grupo de recursos separado para cada ambiente. Em muitas situações, é melhor criar assinaturas separadas do Azure para cada ambiente. Você então pode criar vários grupos de recursos dentro da assinatura de cada ambiente.
Aplique atribuições de função do Azure para que usuários e entidades de serviço possam acessar somente os ambientes necessários. Tenha cuidado para limitar o acesso ao seu ambiente de produção a um pequeno conjunto de pessoas e à entidade de serviço de implantação para esse ambiente.