Partilhar via


Recomendações para projetar uma cadeia de suprimentos de desenvolvimento de carga de trabalho

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

OE:06 Crie uma cadeia de suprimentos de carga de trabalho que impulsione as mudanças propostas por meio de pipelines previsíveis e automatizados. Os pipelines testam e promovem essas alterações em todos os ambientes. Otimize uma cadeia de suprimentos para tornar sua carga de trabalho confiável, segura, econômica e eficiente.

Este guia descreve as recomendações para projetar uma cadeia de suprimentos de desenvolvimento de carga de trabalho baseada em pipelines de integração contínua e entrega contínua (CI/CD). Desenvolva uma cadeia de suprimentos para garantir que você tenha um método previsível e padronizado de manter sua carga de trabalho. Os pipelines de CI/CD são a manifestação da cadeia de suprimentos, mas você deve ter uma única cadeia de suprimentos. E você pode ter vários pipelines que seguem os mesmos processos e usam as mesmas ferramentas.

Incorpore uma cadeia de suprimentos para proteger sua carga de trabalho contra danos que podem ocorrer quando você não gerencia adequadamente as alterações da carga de trabalho. Esteja sempre atento ao estado da sua carga de trabalho, para não correr o risco de ter um comportamento imprevisível. Esse risco aumenta se você precisar gastar tempo crítico refazendo mudanças não contabilizadas quando surgem problemas. Para minimizar esses riscos, padronize os processos e as ferramentas que definem sua cadeia de suprimentos e garanta que sua equipe de carga de trabalho se comprometa totalmente com seu uso.

Definição

Termo Definição
Cadeia de fornecimento Em cargas de trabalho na nuvem, uma cadeia de suprimentos é um conjunto padronizado de ferramentas e processos que você usa para afetar a infraestrutura e a mudança de aplicativos em todos os ambientes.

Principais estratégias de design

Nota

As recomendações neste guia referem-se a ambientes de carga de trabalho em uma cadeia de promoção de código. Sandbox ou outros ambientes exploratórios e de prova de conceito exigem menos rigor e estrutura.

As recomendações a seguir podem ajudá-lo a definir os princípios fundamentais da sua cadeia de suprimentos.

Impor uma política rigorosa de implantações automatizadas baseadas em modelos

Faça alterações propostas na carga de trabalho por meio de processos e ferramentas da cadeia de suprimentos. Imponha uma política rigorosa de implantações automatizadas baseadas em modelos. Esse método ajuda a garantir que a configuração da carga de trabalho em todos os ambientes seja padronizada, bem definida e rigorosamente controlada. Para ambientes em uma cadeia de promoção de código, não execute atualizações usando processos manuais ou interação humana com o plano de controle da plataforma de nuvem, por exemplo, o portal ou uma API. Incorpore todas as alterações no ambiente por meio de um pipeline seguindo as práticas de implantação definidas por você. Para ajudar a aplicar essa política, considere limitar o acesso a somente leitura como padrão e usar uma porta de autorização de acesso para permitir o acesso de gravação.

Um aspeto importante desse princípio é que todas as alterações são propostas até que sejam implantadas em produção. Por meio de testes automatizados, como integração e testes de fumaça, você permite que sua cadeia de suprimentos rejeite automaticamente as alterações.

Implante infraestrutura repetível e imutável como código

Implante infraestrutura repetível e imutável como código (IaC). IaC é o gerenciamento de infraestrutura em um modelo descritivo que usa um sistema de versionamento que espelha o código-fonte. Quando você cria um aplicativo, o mesmo código-fonte deve gerar o mesmo binário toda vez que é compilado. Da mesma forma, um modelo IaC gera o mesmo ambiente toda vez que é aplicado.

Incorpore o IaC para garantir que sua equipe siga um processo padrão e bem estabelecido. Algumas organizações designam um único indivíduo ou um pequeno grupo de indivíduos para implantar e configurar a infraestrutura. Quando você implementa um processo totalmente automatizado, as implantações de infraestrutura exigem menos gerenciamento de indivíduos. A responsabilidade é transferida para o processo de automação e ferramentas. Os membros da equipe podem iniciar implantações de infraestrutura para manter a consistência e a qualidade.

Projete sua carga de trabalho como um grupo lógico de componentes que você pode agrupar em um modelo para tornar as implantações fáceis e repetíveis. Você pode pensar nesses pacotes como selos ou unidades de escala. Para obter mais informações, consulte Padrão de carimbos de implantação. Quando precisar implantar sua carga de trabalho para expandir para outra região ou zona dentro da mesma região, implante um carimbo usando um pipeline. Dependendo de como você cria seus carimbos, você pode implantar um subconjunto de sua carga de trabalho em vez de toda a carga de trabalho. Inclua componentes de rede em seus pipelines de IaC para garantir que seus carimbos de implantação se conectem automaticamente aos recursos existentes.

Para otimizar seu pipeline de IaC para consistência e eficiência, projete uma infraestrutura imutável em vez de uma infraestrutura mutável. Implemente uma infraestrutura imutável para garantir que todos os sistemas no escopo sejam substituídos pela configuração atualizada simultaneamente e de forma idêntica a cada implantação.

Use o mesmo conjunto de artefatos de implantação em todos os ambientes

Use um conjunto de ativos de código e artefatos em todos os ambientes e pipelines. Um ponto problemático comum para as organizações é quando os ambientes de não produção são diferentes dos ambientes de produção. A criação manual de ambientes de produção e não produção pode resultar em configurações incompatíveis entre os ambientes. Essa incompatibilidade retarda os testes e torna mais provável que as alterações possam prejudicar um sistema de produção. Uma abordagem IaC minimiza esses problemas. Ao usar a automação IaC, você pode usar os mesmos arquivos de configuração de infraestrutura para todos os ambientes para produzir ambientes quase idênticos. Você pode adicionar parâmetros aos arquivos de configuração de infraestrutura e ajustá-los para atender aos requisitos de cada ambiente.

Para controlar os custos, normalmente há uma variação entre ambientes de produção e não produção. Muitas vezes, você não precisa do mesmo grau de redundância e desempenho em ambientes que não são de produção como na produção. O número e a SKU dos seus recursos podem diferir entre ambientes. Certifique-se de controlar e entender a variância usando parâmetros padronizados para ajudá-lo a manter a previsibilidade à medida que faz alterações.

Refletir a estrutura organizacional na cadeia de suprimentos

Reflita sua estrutura organizacional em sua cadeia de suprimentos e projetos de pipeline. Sua organização pode estar isolada entre as equipes. Cada equipa pode gerir uma parte da cadeia de abastecimento. Por exemplo, muitas organizações têm equipes que gerenciam domínios de infraestrutura, como redes, dados e recursos de computação. Essas equipes são separadas das equipes de desenvolvimento que gerenciam o desenvolvimento, testes e implantações de aplicativos. Em algumas organizações, as equipes de desenvolvimento e infraestrutura são incorporadas às equipes de DevOps que gerenciam coletivamente todas as implantações de infraestrutura e aplicativos. Há muitas maneiras de organizar as equipes envolvidas em uma cadeia de suprimentos. Sua cadeia de suprimentos depende de todas as equipes trabalhando perfeitamente juntas. Garantir que todas as equipes sigam processos padrão e usem ferramentas padrão para tornar a cadeia de suprimentos o mais eficiente possível.

Sua cadeia de suprimentos pode depender de fornecedores terceirizados se você terceirizar partes do ciclo de vida da carga de trabalho. Esses fornecedores são tão críticos para o sucesso de sua cadeia de suprimentos quanto os recursos internos. Certifique-se de que há um acordo mútuo entre todas as equipes sobre os processos e ferramentas que você usa.

Escolha o método de implantação correto

Padronize seu método de implantação. Fale com o proprietário do produto sobre a quantidade aceitável de tempo de inatividade de produção para sua carga de trabalho. Dependendo de quanto, se houver, tempo de inatividade é aceitável, você pode escolher o método de implantação certo para suas necessidades. Idealmente, você deve executar implantações durante uma janela de manutenção para reduzir a complexidade e o risco. Se nenhum tempo de inatividade for aceitável, empregue um método de implantação azul-verde.

Use uma abordagem de exposição progressiva para reduzir o risco de introduzir bugs não detetados para seus clientes em geral. Também conhecido como implantações canárias, esse método é implantado em grupos controlados de usuários em uma sequência gradual. Ele deteta problemas antes que eles afetem mais usuários. O grupo de distribuição inicial pode ser uma subseção de seus clientes que estão cientes da estratégia de implantação. Esta subseção de clientes pode tolerar alguma quantidade de comportamento inesperado e fornecer feedback. Ou pode ser um grupo de usuários internos, o que ajuda a conter o raio de explosão de bugs durante a implantação.

Ao definir seu método de implantação, adote uma política padrão de implantar apenas a menor alteração viável em cada implantação. Dependendo de fatores como a criticidade da carga de trabalho e a complexidade dos componentes, determine a menor alteração viável. Se você usar uma infraestrutura imutável, a menor alteração viável normalmente é a implantação de recursos com a configuração mais recente para substituir recursos que executam a versão anterior. Se você usar uma infraestrutura mutável, poderá decidir que a menor alteração viável é apenas uma única atualização no grupo de recursos no escopo.

Siga uma abordagem em camadas

Siga uma abordagem em camadas para refletir diferentes ciclos de vida. As camadas fundamentais devem permanecer estáticas durante a maior parte do ciclo de vida da carga de trabalho e as camadas de aplicativos mudam com frequência. Para levar em conta essas diferenças, você deve ter pipelines diferentes para efetuar alterações em cada camada.

Uma zona de pouso está na camada mais baixa. Uma zona de aterrissagem é um agrupamento lógico de elementos fundamentais, como assinaturas, grupos de gerenciamento, grupos de recursos, funções de governança e topologia de rede. Uma zona de aterrissagem permite que você implante e gerencie facilmente sua carga de trabalho e fornece às equipes centrais de operações, ou equipes de plataforma, uma abordagem repetível para uma configuração ambiental. Para fornecer ambientes consistentes, todas as zonas de aterrissagem do Azure fornecem um conjunto de áreas de design comuns, uma arquitetura de referência, uma implementação de referência e um processo para modificar uma implantação para atender aos seus requisitos de design. Os princípios de design da zona de aterrissagem do Azure fornecem práticas recomendadas com base na governança orientada por políticas juntamente com a democratização da assinatura. Uma zona de aterrissagem deve exigir alterações mínimas ao longo do ciclo de vida da carga de trabalho. Para ver um exemplo de uma zona de aterrissagem, consulte O que é uma zona de aterrissagem do Azure. Essa arquitetura conceitual fornece um conjunto de opiniões recomendadas para o Azure.

Sua infraestrutura e funções principais, como controladores de rede de entrada e saída, balanceamento de carga, soluções de roteamento de rede, gerenciamento de DNS e servidores núcleo, também devem exigir grandes alterações pouco frequentes. Mas eles podem exigir atualizações de configuração frequentes.

Seu aplicativo e camada de dados exigem atualizações de configuração frequentes e alterações frequentes na infraestrutura. Esses componentes devem ter os pipelines mais dinâmicos.

Incorporar tipos abrangentes de testes

Planeje uma estratégia de teste holística. Um princípio fundamental da fiabilidade do sistema é o princípio da deslocação para a esquerda . Desenvolver e implantar um aplicativo é um processo descrito como uma série de etapas que vão da esquerda para a direita. Você não deve limitar os testes ao final do processo. Na medida do possível, mude o teste para o início ou para a esquerda. Os erros são mais baratos de reparar quando os apanha cedo. Eles podem ser caros ou impossíveis de corrigir mais tarde no ciclo de vida do aplicativo.

Teste todo o código, incluindo código de aplicativo, modelos de infraestrutura e scripts de configuração. O ambiente que executa aplicativos deve ser controlado por versão e implantado por meio dos mesmos mecanismos que o código do aplicativo. Você pode testar e validar o ambiente usando os mesmos paradigmas de teste que suas equipes já usam para o código do aplicativo.

Sempre que possível, use testes automatizados para garantir a consistência. Inclua os seguintes tipos de testes no design da sua cadeia de suprimentos.

  • Teste de unidade: Os testes de unidade são normalmente executados como parte de uma rotina de integração contínua. Os testes unitários devem ser extensivos e rápidos. Idealmente, eles devem cobrir 100% do código e ser executados em menos de 30 segundos.

    Implemente testes de unidade para verificar se a sintaxe e a funcionalidade de módulos individuais de código funcionam da maneira que deveriam, por exemplo, produzindo uma saída definida para uma entrada conhecida. Você também pode usar testes de unidade para verificar se os ativos IaC são válidos.

    Aplique testes de unidade a todos os ativos de código, incluindo modelos e scripts.

  • Teste de fumaça: Os testes de fumaça verificam se uma carga de trabalho pode ser mantida em um ambiente de teste e tem o desempenho esperado. Os testes de fumaça não verificam a interoperabilidade dos componentes.

    Os testes de fumaça verificam se a metodologia de implantação da infraestrutura e do aplicativo funciona e se o sistema responde como pretendido após a conclusão do processo.

  • Teste de integração: os testes de integração garantem que os componentes do aplicativo operem individualmente e, em seguida, determinem se os componentes podem interagir uns com os outros como deveriam.

    Pode levar uma quantidade considerável de tempo para executar um grande conjunto de testes de integração. É por isso que é melhor incorporar o princípio shift left e realizar testes no início do ciclo de vida de desenvolvimento de software. Reserve testes de integração para cenários que você não pode testar com um teste de fumaça ou teste de unidade.

    Você pode executar processos de teste de longa duração em um intervalo regular, se necessário. Um intervalo regular oferece um bom compromisso e deteta problemas de interoperabilidade entre componentes de aplicativos o mais tardar um dia após sua introdução.

    Alguns cenários de teste se beneficiam de execuções manuais. Use testes manuais quando precisar introduzir elementos de interatividade humana nos testes.

  • Teste de aceitação: Dependendo do contexto, você pode executar manualmente testes de aceitação. Pode ser parcial ou totalmente automatizado. Os testes de aceitação determinam se o sistema de software atende às especificações de requisitos.

    O principal objetivo deste teste é avaliar a conformidade do sistema com os requisitos de negócios e determinar se o sistema atende aos critérios exigidos para entrega aos usuários finais.

Implementar portas de qualidade em processos de promoção de código

Implemente portas de qualidade em todo o seu processo de promoção de código por meio de testes. Implante seu código em ambientes inferiores, como desenvolvimento e teste, e em ambientes superiores, como preparação e produção. À medida que sua implantação passa por portas de qualidade, certifique-se de que ela atenda às suas metas de qualidade antes que as alterações entrem em produção. Seus requisitos de negócios determinam qual é o foco de suas portas de qualidade. Considere também os princípios fundamentais da estrutura bem arquitetada: segurança, confiabilidade e eficiência de desempenho.

Integre também fluxos de trabalho de aprovação em seus portões de qualidade. Defina e automatize claramente os fluxos de trabalho de aprovação quando apropriado. Defina critérios de aceitação de qualidade em sua automação, para que você possa passar por seus portões de forma eficiente e segura.

Facilitação do Azure

O Azure DevOps é uma coleção de serviços que ajudam você a criar uma prática de desenvolvimento colaborativa, eficiente e consistente.

O Azure Pipelines fornece serviços de compilação e lançamento para dar suporte a CI/CD em seus aplicativos.

O GitHub Actions for Azure integra-se ao Azure para simplificar as implantações. Use as Ações do GitHub para automatizar processos de CI/CD. Você pode criar fluxos de trabalho que criam e testam cada solicitação pull para seu repositório ou implantar solicitações pull mescladas na produção.

Você pode usar o Terraform, o Bíceps e o Azure Resource Manager para implantações do IaC. Dependendo dos seus requisitos e da familiaridade da sua equipa com as ferramentas, poderá utilizar uma ou mais destas ferramentas para as suas implementações e gestão dos recursos.

Exemplo

Para obter um exemplo que mostra como usar o Azure Pipelines para criar um pipeline de CI/CD, consulte Arquitetura de linha de base do Azure Pipelines.

Lista de verificação de Excelência da Operação

Consulte o conjunto completo de recomendações.