Compartilhar via

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

  • Artigo

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 fornecimento de carga de trabalho que conduza as alterações propostas por meio de pipelines automatizados e previsíveis. 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 fornecedores para garantir um método previsível e padronizado a fim de manter a carga de trabalho. Os pipelines de CI/CD são a manifestação da cadeia de fornecedores, mas você deverá ter uma única cadeia de fornecedores. 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 de carga de trabalho. Esteja sempre ciente do estado da sua carga de trabalho, para que você não corra o risco de ter um comportamento imprevisível. Esse risco aumenta se você precisar gastar tempo crítico refazendo alterações não contabilizadas quando surgirem 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 fornecedores Em cargas de trabalho na nuvem, uma cadeia de suprimentos é um conjunto padronizado de ferramentas e processos que você usa para afetar a mudança de infraestrutura e aplicativos em todos os ambientes.

Principais estratégias de design

Observação

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.

Princípios fundamentais

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

Faça alterações de carga de trabalho propostas por meio de processos e ferramentas da cadeia de suprimentos. Aplique 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 rigidamente 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 ao ambiente por meio de um pipeline seguindo as práticas de implantação que você definir. Para ajudar a impor essa política, considere limitar o acesso a somente leitura como padrão e usar uma porta de autorização de acesso para permitir acesso de gravação.

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

Implantar infraestrutura repetível e imutável como código (IaC). O IaC é o gerenciamento da infraestrutura em um modelo descritivo que usa um sistema de controle de versão que espelha o código-fonte. Ao criar um aplicativo, o mesmo código-fonte gera o mesmo binário sempre que é compilado. De maneira semelhante, um modelo de IaC gera o mesmo ambiente sempre 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 dos indivíduos. A responsabilidade é transferida para o processo de automação e ferramental. 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 você 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 IaC para garantir que seus carimbos de implantação se conectem automaticamente aos recursos existentes.

Para otimizar seu pipeline 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 um conjunto de ativos de código e artefatos em todos os ambientes e pipelines. Um ponto problemático para as organizações é quando ambientes de não produção são diferentes dos ambientes de produção. Criar ambientes de produção e não produção manualmente 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 do que em produção. O número e a SKU de seus recursos podem diferir entre os ambientes. Certifique-se de controlar e entender a variação usando parâmetros padronizados para ajudá-lo a manter a previsibilidade à medida que faz alterações.

Reflita sua estrutura organizacional em sua cadeia de suprimentos e projetos de pipeline. Sua organização pode estar isolada entre as equipes. Cada equipe pode gerenciar uma parte da cadeia de suprimentos. Por exemplo, muitas organizações têm equipes que gerenciam domínios de infraestrutura, como rede, dados e recursos de computação. Essas equipes são separadas das equipes de desenvolvimento que gerenciam o desenvolvimento, os testes e as 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. Existem muitas maneiras de organizar as equipes que estão 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 haja um acordo mútuo entre todas as equipes sobre os processos e ferramentas que você usa.

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 do quanto tempo de inatividade, se houver, for aceitável, você pode escolher o método de implantação correto para seus requisitos. 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 detectados 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 detecta 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 distribuição. Esta subseção de clientes pode tolerar alguma quantidade de comportamento inesperado e fornecer comentários. Ou pode ser um grupo de usuários internos, o que ajuda a conter o raio de explosão de bugs durante a distribuiçã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 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 aplicativo mudam com frequência. Para considerar 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 de operações centrais, 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 alterações importantes 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 de infraestrutura. Esses componentes devem ter os pipelines mais dinâmicos.

Planeje uma estratégia holística de testes. Um princípio central da confiabilidade do sistema é o princípio de deslocamento 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 o teste 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 você os pega 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.

Quando possível, use testes automatizados para garantir a consistência. Inclua os seguintes tipos de teste no design da 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 extensos e rápidos. O ideal é que eles cubram 100% do código e sejam executados em menos de 30 segundos.

    Implemente o teste 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 levantada em um ambiente de teste e funciona conforme o 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, determinam 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 de deslocamento para a esquerda 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 execução em um intervalo regular, se necessário. Um intervalo regular oferece um bom compromisso e detecta problemas de interoperabilidade entre componentes de aplicativos no máximo 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 o teste de aceitação. Pode ser parcial ou totalmente automatizado. O teste de aceitação determina se o sistema de software atende às especificações de requisito.

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

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 preparo e produção. À medida que sua implantação passa pelos portões 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 seus portões de qualidade. Considere também os princípios fundamentais do Well-Architected Framework: Segurança, Confiabilidade e Eficiência de Desempenho.

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

Azure facilitation

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 em seu repositório ou implantar solicitações pull mescladas na produção.

Você pode usar o Terraform, o Bicep e o Gerenciador de Recursos do Azure para implantações de IaC. Dependendo de seus requisitos e da familiaridade de sua equipe com as ferramentas, você pode usar uma ou mais dessas ferramentas para suas implantações e gerenciamento 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 em Operação

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional