Recomendações para conceber uma cadeia de fornecimento de desenvolvimento de cargas 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 cargas de trabalho que conduza as alterações propostas através de pipelines automatizados previsíveis. Os pipelines testam e promovem essas alterações entre ambientes. Otimize uma cadeia de fornecimento para tornar a carga de trabalho fiável, segura, rentável e eficaz.

Este guia descreve as recomendações para conceber uma cadeia de fornecimento de desenvolvimento de cargas de trabalho baseada em pipelines de integração contínua e entrega contínua (CI/CD). Desenvolva uma cadeia de fornecimento para garantir que tem um método padronizado previsível para manter a carga de trabalho. Os pipelines CI/CD são a manifestação da cadeia de fornecimento, mas deve ter uma única cadeia de fornecimento. Além disso, poderá ter vários pipelines que seguem os mesmos processos e utilizam as mesmas ferramentas.

Incorpore uma cadeia de fornecimento para proteger a carga de trabalho contra danos que podem ocorrer quando não gere corretamente as alterações à carga de trabalho. Tenha sempre em atenção o estado da sua carga de trabalho, pelo que não corre o risco de ter um comportamento imprevisível. Este risco é composto se precisar de passar um tempo crítico a repetir alterações não contabilizadas quando surgem problemas. Para minimizar estes riscos, uniformize os processos e ferramentas que definem a cadeia de fornecimento e certifique-se de que a equipa de carga de trabalho se compromete totalmente com a sua utilização.

Definição

Termo Definição
Cadeia de fornecimento Nas cargas de trabalho na cloud, uma cadeia de fornecimento é um conjunto padronizado de ferramentas e processos que utiliza para afetar a infraestrutura e a alteração de aplicações em ambientes.

Principais estratégias de conceção

Nota

As recomendações neste guia referem-se aos ambientes de carga de trabalho numa cadeia de promoção de código. O sandbox ou outros ambientes exploratórios e de prova de conceito requerem menos rigor e estrutura.

Princípios principais

As recomendações seguintes podem ajudá-lo a definir os princípios principais da cadeia de fornecimento.

Faça alterações propostas à carga de trabalho através de processos e ferramentas da cadeia de fornecimento. Impor uma política rigorosa de implementações automatizadas baseadas em modelos. Este método ajuda a garantir que a configuração da carga de trabalho em todos os ambientes é padronizada, bem definida e controlada de forma rigorosa. Para ambientes numa cadeia de promoção de código, não efetue atualizações utilizando processos manuais ou interação humana com o plano de controlo da plataforma cloud, por exemplo, o portal ou uma API. Incorpore todas as alterações ao ambiente através de um pipeline ao seguir as práticas de implementação que definir. Para ajudar a impor esta política, considere limitar o acesso ao modo só de leitura como predefinição e utilizar uma porta de autorização de acesso para permitir o acesso de escrita.

Um aspeto importante deste princípio é que todas as alterações são propostasaté serem implementadas na produção. Através de testes automatizados, como a integração e o teste rápido, permite que a cadeia de fornecimento rejeite automaticamente as alterações.

Implemente uma infraestrutura repetível e imutável como código (IaC). A IaC é a gestão da infraestrutura num modelo descritivo que utiliza um sistema de controlo de versões que espelha o código fonte. Quando cria uma aplicação, o mesmo código fonte deve gerar o mesmo binário sempre que for compilado. Da mesma forma, um modelo IaC gera o mesmo ambiente sempre que é aplicado.

Incorpore IaC para garantir que a sua equipa segue um processo padrão e bem estabelecido. Algumas organizações designam um único grupo individual ou pequeno de indivíduos para implementar e configurar a infraestrutura. Quando implementa um processo totalmente automatizado, as implementações de infraestrutura requerem menos gestão por parte dos indivíduos. A responsabilidade é transferida para o processo de automatização e ferramentas. Os membros da equipa podem iniciar implementações de infraestrutura para manter a consistência e a qualidade.

Crie a carga de trabalho como um grupo lógico de componentes que pode agrupar num modelo para tornar as implementações fáceis e repetíveis. Pode considerar estes pacotes como selos ou unidades de escala. Para obter mais informações, veja Deployment Stamps pattern (Padrão de Selos de Implementação). Quando precisar de implementar a carga de trabalho para aumentar horizontalmente para outra região ou zona na mesma região, implemente um selo com um pipeline. Consoante a forma como estrutura os seus selos, poderá implementar um subconjunto da carga de trabalho em vez de toda a carga de trabalho. Inclua componentes de rede nos pipelines IaC para garantir que os selos de implementação se ligam automaticamente aos recursos existentes.

Para otimizar o pipeline iaC para consistência e eficiência, crie uma infraestrutura imutável em vez de uma infraestrutura mutável. Implemente uma infraestrutura imutável para garantir que todos os sistemas no âmbito são substituídos pela configuração atualizada em simultâneo e de forma idêntica com cada implementação.

Utilize um conjunto de recursos de código e artefactos em todos os ambientes e pipelines. Um ponto de dor comum para as organizações é quando os ambientes de não produção são diferentes dos ambientes de produção. Criar ambientes de produção e de não produção manualmente pode resultar em configurações desajustadas entre os ambientes. Este erro de correspondência atrasa os testes e torna mais provável que as alterações possam prejudicar um sistema de produção. Uma abordagem IaC minimiza estes problemas. Quando utiliza a automatização IaC, pode utilizar os mesmos ficheiros de configuração de infraestrutura para todos os ambientes para produzir ambientes quase idênticos. Pode adicionar parâmetros aos ficheiros de configuração da infraestrutura e ajustá-los para cumprir os requisitos de cada ambiente.

Para controlar os custos, normalmente existe uma variância entre ambientes de produção e de não produção. Muitas vezes, não precisa do mesmo grau de redundância e desempenho em ambientes de não produção como em produção. O número e o SKU dos seus recursos podem diferir entre ambientes. Certifique-se de que controla e compreende a variância com parâmetros padronizados para o ajudar a manter a previsibilidade à medida que faz alterações.

Reflita a sua estrutura organizacional nas suas estruturas de cadeia de fornecimento e pipeline. A sua organização pode estar siloed entre as equipas. Cada equipa pode gerir uma parte da cadeia de fornecimento. Por exemplo, muitas organizações têm equipas que gerem domínios de infraestrutura, como redes, dados e recursos de computação. Estas equipas são separadas das equipas de desenvolvimento que gerem desenvolvimento de aplicações, testes e implementações. Em algumas organizações, as equipas de desenvolvimento e infraestrutura são incorporadas em equipas de DevOps que gerem coletivamente todas as implementações de infraestruturas e aplicações. Existem várias formas de organizar as equipas envolvidas numa cadeia de fornecimento. A sua cadeia de fornecimento depende de todas as equipas que trabalham em conjunto de forma totalmente integrada. Certifique-se de que todas as equipas seguem os processos padrão e utilizam ferramentas padrão para tornar a cadeia de fornecimento o mais eficiente possível.

A cadeia de fornecimento poderá depender de fornecedores de terceiros se subcontratar partes do ciclo de vida da carga de trabalho. Estes fornecedores são tão críticos para o sucesso da cadeia de fornecimento como os recursos internos. Certifique-se de que existe um acordo mútuo entre todas as equipas sobre os processos e ferramentas que utiliza.

Uniformize o seu método de implementação. Fale com o proprietário do produto sobre a quantidade aceitável de tempo de inatividade de produção para a carga de trabalho. Consoante a quantidade de tempo de inatividade aceitável, pode escolher o método de implementação adequado para os seus requisitos. Idealmente, deve efetuar implementações durante uma janela de manutenção para reduzir a complexidade e o risco. Se não for aceitável um período de indisponibilidade, empregue um método de implementação azul-verde.

Utilize uma abordagem de exposição progressiva para reduzir o risco de introdução de erros não detetados aos seus clientes em geral. Também conhecido como implementações canary, este método implementa em grupos controlados de utilizadores numa sequência gradual. Deteta problemas antes de afetarem mais utilizadores. O grupo de implementação inicial pode ser uma subsecção dos seus clientes que estão cientes da estratégia de implementação. Esta subsecção de clientes pode tolerar algum comportamento inesperado e fornecer feedback. Ou pode ser um grupo de utilizadores internos, o que ajuda a conter o raio de explosão de erros durante a implementação.

Quando definir o seu método de implementação, adote uma política padrão para implementar apenas a menor alteração viável em cada implementação. Dependendo de fatores como a importância da carga de trabalho e a complexidade dos componentes, determine a menor alteração viável. Se utilizar uma infraestrutura imutável, a menor alteração viável é normalmente a implementação de recursos com a configuração mais recente para substituir os recursos que executam a versão anterior. Se utilizar uma infraestrutura mutável, poderá decidir que a menor alteração viável é apenas uma única atualização no grupo de recursos no âmbito.

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 da aplicação mudam frequentemente. Para ter em conta estas diferenças, 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 subscrições, grupos de gestão, grupos de recursos, funções de governação e topologia de rede. Uma zona de destino permite-lhe implementar e gerir facilmente a sua carga de trabalho e fornece equipas de operações centrais, ou equipas de plataforma, com uma abordagem repetível a 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 implementação de acordo com os seus requisitos de conceção. Os princípios de conceção da zona de destino do Azure fornecem práticas recomendadas baseadas na governação orientada por políticas, juntamente com a democratização da subscrição. Uma zona de destino 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, veja O que é uma zona de destino do Azure. Esta arquitetura conceptual fornece um conjunto de opiniões recomendadas para o Azure.

A infraestrutura e as funções principais, como controladores de rede de entrada e saída, balanceamento de carga, soluções de encaminhamento de rede, gestão de DNS e servidores principais, também devem exigir alterações importantes pouco frequentes. Contudo, podem necessitar de atualizações de configuração frequentes.

A aplicação e a camada de dados requerem atualizações de configuração frequentes e alterações frequentes da infraestrutura. Estes componentes devem ter os pipelines mais dinâmicos.

Planeie uma estratégia de teste holística. Um princípio fundamental da fiabilidade do sistema é o princípio da mudança para a esquerda . Desenvolver e implementar uma aplicação é um processo que é descrito como uma série de passos que vão da esquerda para a direita. Não deve limitar os testes até ao fim do processo. Tanto quanto possível, teste por turnos para o início ou para a esquerda. Os erros são mais baratos de reparar quando os apanha mais cedo. Podem ser dispendiosos ou impossíveis de corrigir mais tarde no ciclo de vida da aplicação.

Teste todo o código, incluindo código da aplicação, modelos de infraestrutura e scripts de configuração. O ambiente que executa aplicações deve ser controlado por versões e implementado através dos mesmos mecanismos que o código da aplicação. Pode testar e validar o ambiente com os mesmos paradigmas de teste que as suas equipas já utilizam para o código da aplicação.

Sempre que possível, utilize testes automatizados para garantir a consistência. Inclua os seguintes tipos de testes na estrutura da cadeia de fornecimento.

  • Teste de unidades: os testes de unidades são normalmente executados como parte de uma rotina de integração contínua. Os testes de unidades devem ser extensos e rápidos. Devem, idealmente, cobrir 100% do código e executar em menos de 30 segundos.

    Implemente testes de unidades para verificar se a sintaxe e a funcionalidade de módulos individuais de código funcionam da forma que devem, por exemplo, produzir uma saída definida para uma entrada conhecida. Também pode utilizar testes de unidades para verificar se os recursos IaC são válidos.

    Aplique testes de unidades a todos os recursos de código, incluindo modelos e scripts.

  • Testes de fumo: os testes de fumo verificam se uma carga de trabalho pode ser suportada num ambiente de teste e é executada conforme esperado. Os testes de fumo não verificam a interoperabilidade dos componentes.

    Os testes de fumo verificam se a metodologia de implementação da infraestrutura e da aplicação funciona e que o sistema responde conforme pretendido após a conclusão do processo.

  • Testes de integração: os testes de integração garantem que os componentes da aplicação funcionam individualmente e, em seguida, determinam se os componentes podem interagir uns com os outros como deveriam.

    Pode demorar muito tempo a executar um conjunto de testes de integração grande. É por isso que é melhor incorporar o princípio shift 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 não pode testar com um teste de fumo ou teste de unidade.

    Pode executar processos de teste de execução prolongada num intervalo regular, se necessário. Um intervalo regular oferece um bom compromisso e deteta problemas de interoperabilidade entre componentes da aplicação o mais tardar um dia depois de serem introduzidos.

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

  • Teste de aceitação: consoante o contexto, pode realizar manualmente testes de aceitação. Pode ser parcial ou totalmente automatizado. O teste de aceitação determina se o sistema de software cumpre as especificações de requisitos.

    O principal objetivo deste teste é avaliar a conformidade do sistema com os requisitos empresariais e determinar se o sistema cumpre os critérios necessários para a entrega aos utilizadores finais.

Implemente portas de qualidade ao longo do processo de promoção de código através de testes. Implemente o código em ambientes mais baixos, como desenvolvimento e testes, e para cima através de ambientes mais elevados, como teste e produção. À medida que a sua implementação passa por portas de qualidade, certifique-se de que cumpre os seus objetivos de qualidade antes de as alterações irem para produção. Os seus requisitos empresariais determinam qual é o foco das suas portas de qualidade. Considere também os princípios fundamentais Well-Architected Framework: Segurança, Fiabilidade e Eficiência de Desempenho.

Integre também fluxos de trabalho de aprovação nas portas de qualidade. Defina e automatize claramente os fluxos de trabalho de aprovação quando adequado. Defina critérios de aceitação de qualidade para a sua automatização, para que possa percorrer as portas de forma eficiente e segura.

Facilitação do Azure

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

O Azure Pipelines fornece serviços de compilação e versão para suportar CI/CD nas suas aplicações.

GitHub Actions do Azure integra-se com o Azure para simplificar as implementações. Utilize GitHub Actions para automatizar processos de CI/CD. Pode criar fluxos de trabalho que compilam e testam todos os pedidos Pull para o seu repositório ou implementar pedidos Pull intercalados para produção.

Pode utilizar o Terraform, o Bicep e o Azure Resource Manager para implementações IaC. Dependendo dos seus requisitos e da familiaridade da sua equipa com as ferramentas, pode utilizar uma ou mais destas ferramentas para as suas implementações e gestão dos recursos.

Exemplo

Para obter um exemplo que mostra como utilizar os Pipelines do Azure para criar um pipeline CI/CD, veja Arquitetura de linha de base dos Pipelines do Azure.

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

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional