Entender os ambientes
Os fluxos de trabalho 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ê 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 GitHub Actions ajudam você a dar suporte ao seu próprio processo.
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. Minimize o risco implantando as alterações em um ambiente que não seja de 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 experimenta a solução e verifica se ela se comporta conforme o esperado e atende aos 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 fluxo de trabalho complexo que é implantado 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 é aprimorar a sua confiança em uma alteração à medida que ela avança no fluxo de trabalho 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 fluxo de trabalho para implantar seu código Bicep no ambiente de teste e executar alguns testes básicos nele. Se esse esforço for bem-sucedido, você poderá implantá-lo em seu ambiente de produção.
Ambientes de fluxo de trabalho
O GitHub Actions também tem o conceito de um ambiente. Você cria um ambiente do GitHub Actions para representar o ambiente que você tem no Azure. Ao definir seu fluxo de trabalho em um arquivo YAML, você pode vincular trabalhos a um ambiente específico. Usando ambientes, você obtém alguns recursos adicionais em seu fluxo de trabalho.
Regras de proteção
Um ambiente no GitHub Actions pode ter regras de proteção configuradas. Sempre que o ambiente for usado em um trabalho em seu fluxo de trabalho, o GitHub Actions garantirá que essas regras sejam atendidas antes que o trabalho comece a ser executado.
Por exemplo, você pode configurar revisões manuais em seu ambiente de produção. Antes do início de uma implantação de produção, o revisor designado recebe uma notificação. 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 confirmar a ramificação da qual a sua alteração é proveniente. Se a alteração não estiver na ramificação principal, você poderá configurar o GitHub para impedir que ela seja implantada em seu ambiente de produção.
Segredos
O GitHub Actions permite armazenar segredos que só podem ser usados com um ambiente específico. Você aprenderá mais sobre o gerenciamento de segredos mais adiante neste módulo.
Histórico de implantações
O GitHub Actions 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 até permite que você rastreie uma implantação para um 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.
Criar ambientes
Você pode criar um ambiente usando a interface da Web do GitHub.
Quando o fluxo de trabalho se refere a um ambiente que não existe, o GitHub Actions o cria automaticamente para você. Esse recurso pode afetar a segurança do repositório GitHub, pois o novo ambiente não terá nenhuma regra de proteção configurada. É melhor criar um ambiente por conta própria por meio da interface da Web do GitHub, para que você tenha controle total sobre a segurança dele.
Vincular um trabalho de implantação a um ambiente
Na definição do fluxo de trabalho de implantação, você pode se referir a um ambiente usando a propriedade environment:
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
Neste exemplo, o trabalho nomeado deploy está vinculado ao ambiente Test.
Ambientes e conexões com o Azure
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 fluxo de trabalho de implantação. Você deve criar identidades de carga de trabalho separadas para cada ambiente. Seguir essa prática 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.
As identidades de carga de trabalho devem ter permissões específicas para implantar somente a assinatura e o grupo de recursos usados por esse ambiente:
Importante
Use uma identidade de carga de trabalho separada para cada ambiente em que você planeja implantar. Conceda à identidade de carga de trabalho 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 identidades de carga de trabalho 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 à identidade de carga de trabalho de implantação para esse ambiente.
Credenciais federadas para ambientes
Quando sua identidade de carga de trabalho se conecta ao Azure no fluxo de trabalho de implantação, ela usa uma credencial federada para se autenticar com segurança sem segredos ou chaves. Em módulos anteriores neste roteiro de aprendizagem, suas credenciais federadas concederam acesso aos fluxos de trabalho de implantação quando elas foram implantadas na ramificação principal do repositório Git.
Ao implantar em um ambiente dentro do seu fluxo de trabalho, você precisa usar uma credencial federada com escopo para esse ambiente.
Neste módulo, o fluxo de trabalho inclui vários trabalhos, muitos dos quais se conectam e se implantam no Azure. Alguns dos trabalhos usam ambientes e outros não. Portanto, você cria duas credenciais federadas para cada uma de suas identidades de carga de trabalho: uma no escopo do ambiente e outra no escopo da ramificação principal.