Compartilhar via

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

  • Artigo

Aplica-se a esta recomendação da lista de verificação do Azure Well-Architected Framework Operational Excellence:

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 de alto desempenho.

Este guia descreve as recomendações para projetar uma cadeia de suprimentos de desenvolvimento de carga de trabalho baseada em pipelines de CI/CD (integração contínua e entrega contínua). 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 da carga de trabalho. Esteja sempre ciente do estado de sua carga de trabalho, para que você não corra o risco de experimentar um comportamento imprevisível. Esse risco aumenta se você precisar gastar um tempo crítico refazendo alterações não contabilizadas quando surgirem problemas. Para minimizar esses riscos, padronize os processos e 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 aplicativo entre 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.

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

Aplique uma política rígida de implantações automatizadas baseadas em modelos

Faça as alterações propostas na carga de trabalho por meio de processos e ferramentas da cadeia de suprimentos. Aplique uma política rígida 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 no ambiente por meio de um pipeline seguindo as práticas de implantação definidas por você. Para ajudar a impor essa política, considere limitar o acesso a somente leitura como padrão e usar um portão de autorização de acesso para permitir o 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 teste 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 como código (IaC) repetível e imutável. 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 a 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 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 selos de implantação. Quando você precisar implantar sua carga de trabalho para escalar horizontalmente em outra região ou zona dentro da mesma região, implante um carimbo usando um pipeline. Dependendo de como você projeta 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 selos 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 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 de IaC minimiza esses problemas. Ao usar a automação de 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 de não produção que precisa na produção. O número e o SKU de seus recursos podem ser diferentes 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 você faz alterações.

Refletir a estrutura organizacional na cadeia de suprimentos

Reflita sua estrutura organizacional em seus projetos de cadeia de suprimentos e 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 recursos de rede, dados e 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 envolvidas em uma cadeia de suprimentos. Sua cadeia de suprimentos depende de todas as equipes trabalhando juntas perfeitamente. Certifique-se de que todas as equipes sigam os 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.

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 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ário, 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. Essa subseção de clientes pode tolerar uma certa 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 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 os 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 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 destino está na camada mais baixa. Uma zona de destino é 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 destino 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 destino 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 destino do Azure fornecem práticas recomendadas com base na governança controlada por políticas, juntamente com a democratização da assinatura. Uma landing zone deve exigir alterações mínimas ao longo do ciclo de vida da carga de trabalho. Para ver um exemplo de uma zona de destino, consulte O que é uma zona de destino 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 sua camada de dados exigem atualizações frequentes de configuração e alterações frequentes de infraestrutura. Esses componentes devem ter os pipelines mais dinâmicos.

Incorpore tipos abrangentes de testes

Planeje uma estratégia de teste holística. Um princípio fundamental da confiabilidade do sistema é o princípio da mudança 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. Tanto quanto possível, mude o teste para o início ou para a esquerda. Os erros são mais baratos de reparar quando você os detecta cedo. Eles podem ser caros ou impossíveis de corrigir posteriormente 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 em seu projeto de cadeia de suprimentos.

  • Teste de unidade: os testes de unidade normalmente são executados como parte de uma rotina de integração contínua. Os testes de unidade devem ser extensos 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 de 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 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 conforme o esperado 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 um tempo considerável 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 detecta problemas de interoperabilidade entre os componentes do aplicativo no máximo um dia após a introdução.

    Alguns cenários de teste se beneficiam de execuções manuais. Use o teste manual 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 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 portões de qualidade em processos de promoção de código

Implemente portões de qualidade em todo o 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 por 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 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 com eficiência e segurança.

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 build e versão para dar suporte a CI/CD em seus aplicativos.

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

Você pode usar o Terraform, o Bicep e o Azure Resource Manager 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 operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional