Compreender os ambientes
Os pipelines de implantação permitem automatizar 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ê deseja revisar as alterações no código antes de implantá-las no ambiente de produção.
Nesta unidade, você aprenderá sobre como os ambientes no Azure Pipelines ajudam a dar suporte ao seu próprio fluxo de trabalho.
Por que você tem vários ambientes?
Os processos de implantação fazem alterações em seus recursos do Azure, incluindo recursos em uso. Alterar recursos envolve algum risco, porque as alterações implantadas podem não se comportar como esperado. Você pode até descobrir que as alterações quebram sua configuração atual.
Para minimizar o risco de problemas, é uma boa prática experimentar as alterações de forma segura antes de implantá-las no ambiente de produção. Por exemplo, você pode implantar as alterações em um ambiente que não seja de produção.
Muitas organizações configuram vários ambientes de não-produção onde implantam progressivamente suas alterações antes de liberá-las para produção. Cada ambiente de não produção serve a um propósito específico e, muitas vezes, tem portas de qualidade específicas que devem ser atendidas para prosseguir para o próximo ambiente. Se algo der errado, como uma falha no teste, a implantação será interrompida. À medida que sua implantação se move em cada ambiente, sua confiança nas mudanças aumenta.
Os ambientes comuns incluem:
Desenvolvimento: Um ambiente de desenvolvimento é normalmente usado por desenvolvedores para tentar suas alterações e iterar rapidamente em seu trabalho.
Os ambientes de desenvolvimento geralmente têm controles mínimos para que os membros da equipe possam experimentar 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 forma segura. Muitas dessas alterações e avaliações podem não avançar em seu processo de implantação, porque você está eliminando as ideias que não são bem-sucedidas.
Em algumas equipes, você pode até configurar um ambiente de desenvolvimento separado para cada membro da equipe para que eles não atrapalhem uns aos outros enquanto estão trabalhando em novos recursos.
Os ambientes de desenvolvimento às vezes também são chamados de ambientes sandbox .
Teste: um ambiente de teste é projetado para executar testes manuais ou automatizados em relação às alterações.
Os 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, testes automatizados podem ser executados em relação a ele. Se todos os testes automatizados passarem, a alteração será segura para mesclar na ramificação principal do projeto. Os testes automatizados geralmente verificam a funcionalidade principal do sistema, juntamente com coisas como violações de política nos recursos recém-implantados.
Você também pode criar ambientes de teste dedicados para tipos específicos de teste, como testes de desempenho e segurança.
Integração: um ambiente de integração pode ajudá-lo a testar quaisquer 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 automaticamente, mas muitas organizações também realizam testes manuais nesse ambiente.
Os ambientes de integração às vezes também são chamados de ambientes de teste de integração de sistema (SIT).
Teste de aceitação do usuário: um ambiente de teste de aceitação do usuário (UAT) é usado para validação manual, geralmente por partes interessadas do negócio em vez de desenvolvedores. Na validação manual, alguém passa pela solução e verifica se ela se comporta como esperado e se atinge os requisitos de negócios necessários. Essa pessoa então aprova as alterações para que a implantação possa continuar.
Pré-produção: um ambiente de pré-produção é muitas vezes um espelho do ambiente de produção, com os mesmos recursos SKUs e configuração. Ele é usado como uma verificação final para verificar como a implantação de produção se comportará durante e após a aplicação da alteração. Ele também pode ser usado para verificar se é esperado algum tempo de inatividade durante a implantação de produção.
Os ambientes de pré-produção às vezes também são chamados de ambientes de preparação .
Produção: seu ambiente de produção é aquele que os usuários finais do aplicativo usam. É o seu ambiente ao vivo que você quer proteger e manter em funcionamento tanto quanto 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 para atender diferentes grupos de clientes.
Demonstração: sua equipe também pode criar ambientes de demonstração (demonstração) para mostrar o aplicativo aos usuários finais, para uso em treinamento ou para que as equipes de vendas mostrem determinados recursos a clientes em potencial. Você pode até ter vários ambientes de demonstração que servem a propósitos diferentes. Um ambiente de demonstração geralmente é uma réplica reduzida do seu ambiente de produção, com dados falsos de clientes.
Ambientes na sua organização
Você pode ver variações desses ambientes. Algumas organizações usam apenas alguns ambientes e outras usam muitos mais. 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 único ambiente assume o papel de vários dos ambientes listados anteriormente. Outras vezes, você pode ter um pipeline complexo que é implantado em vários ambientes, alguns em paralelo e outros em sequência. Algumas organizações até excluem ou desprovisionam automaticamente os ambientes quando eles não são mais usados e, em seguida, os reimplantam quando são necessários no futuro.
Seja qual for a sua organização escolhida como sua lista de ambientes, o objetivo é melhorar sua confiança em uma mudança à medida que ela progride em seu pipeline de implantação. Quando uma alteração não atende aos seus requisitos de qualidade, você deseja poder interromper a implantação dessa alteração em quaisquer ambientes subsequentes na cadeia.
Na sua empresa de brinquedos, você decide começar com um conjunto básico de ambientes para o seu site. Além do ambiente de produção, você criará um ambiente que não seja de produção chamado Test:
Você atualizará seu pipeline para implantar seu código Bicep em seu ambiente de teste e executar alguns testes básicos em relação a ele. 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ê obtém alguns outros recursos em seu pipeline.
Verificações e aprovações
Um ambiente no Azure DevOps pode ter verificações e aprovações configuradas. Cada vez que o ambiente é usado em um trabalho em seu pipeline, o Azure DevOps garante que essas verificações e aprovações sejam bem-sucedidas antes que o trabalho comece a ser executado.
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 e-mail. 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 como esperado no ambiente de pré-produção antes de aprovar a implantação.
Além disso, você pode executar uma verificação automatizada para revisar os logs e as taxas de erro em seu ambiente de pré-produção após a última implantação. Se a verificação confirmar que o número de erros não aumentou substancialmente, permitirá que a implantação prossiga.
Histórico de implementações
O Azure Pipelines rastreia o histórico das implantações em um ambiente. Esse histórico oferece uma maneira fácil de acompanhar o que acontece no ambiente ao longo do tempo. Ele ainda permite que você rastreie uma implantação para uma solicitação de recurso específica em seus itens de trabalho do Azure Boards ou para uma confirmação em seu repositório. Esse recurso pode 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 a ambientes. Você pode restringir os pipelines que têm permissão para usar um ambiente específico. Ou impeça 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 novos ambientes, modifiquem ambientes e visualizem ambientes e o histórico de implantações para eles.
Nota
Quando seu 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 seu projeto de DevOps do Azure porque você obterá automaticamente permissões administrativas para o ambiente. É melhor criar um ambiente por conta própria por meio da interface da Web do Azure DevOps, para que você tenha controle total sobre sua segurança e não obtenha 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 deployment propriedade para especificar um trabalho de implantação e especifica o nome do ambiente no qual o trabalho implanta:
- 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 Test ambiente.
Gorjeta
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. Ligamos 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 seu ambiente de desenvolvimento não deve ser capaz de acessar um banco de dados dentro do 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 que não sejam de 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 sua própria entidade de serviço dedicada, com permissões específicas para implantar somente na assinatura e no 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 no qual 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 do Azure separadas para cada ambiente. Em seguida, você pode criar vários grupos de recursos dentro da assinatura de cada ambiente.
Aplique atribuições de função do Azure para que os usuários e entidades de serviço possam acessar apenas os ambientes que precisam acessar. E 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 desse ambiente.