Implantação e teste de cargas de trabalho críticas no Azure

Implantações com falha e versões incorretas são causas comuns de paralisações de aplicativos. Sua abordagem de implantação e teste desempenha um papel crítico na confiabilidade geral de um aplicativo de missão crítica.

A implantação e os testes devem formar a base para todas as operações de aplicativos e infraestrutura para garantir resultados consistentes para cargas de trabalho de missão crítica. Esteja preparado para implantar semanalmente, diariamente ou com mais frequência. Projete seus pipelines de integração contínua e implantação contínua (CI/CD) para dar suporte a essas metas.

A estratégia deve implementar:

• Rigorosos testes de pré-lançamento. As atualizações não devem apresentar defeitos, vulnerabilidades ou outros fatores que possam comprometer a integridade do aplicativo.

• Implantações transparentes. Deve ser possível lançar atualizações a qualquer momento sem afetar os usuários. Os usuários devem ser capazes de continuar suas interações com o aplicativo sem interrupção.

• Operações altamente disponíveis. Os processos e ferramentas de implantação e teste devem estar altamente disponíveis para oferecer suporte à confiabilidade geral do aplicativo.

• Processos de implantação consistentes. Os mesmos artefatos e processos de aplicativo devem ser usados para implantar a infraestrutura e o código do aplicativo em ambientes diferentes. A automação de ponta a ponta é obrigatória. Intervenções manuais devem ser evitadas, pois podem trazer riscos à confiabilidade.

Esta área de design fornece recomendações sobre como otimizar os processos de implantação e teste com o objetivo de minimizar o tempo de inatividade e manter a integridade e a disponibilidade do aplicativo.

Importante

Este artigo faz parte da série de cargas de trabalho de missão crítica do Azure Well-Architected Framework. Se você não estiver familiarizado com esta série, recomendamos que você comece com O que é uma carga de trabalho de missão crítica?.

Implantação sem tempo de inatividade

Assista ao vídeo a seguir para obter uma visão geral da implantação sem tempo de inatividade.

Alcançar implantações de tempo de inatividade zero é uma meta fundamental para aplicativos de missão crítica. Seu aplicativo precisa estar disponível o dia todo, todos os dias, mesmo quando novas versões são lançadas durante o horário comercial. Invista seus esforços antecipadamente para definir e planejar processos de implantação, a fim de conduzir decisões de design importantes, como tratar os recursos como efêmeros.

Para obter uma implantação sem tempo de inatividade, implante uma nova infraestrutura ao lado da infraestrutura existente, teste-a completamente, faça a transição do tráfego do usuário final e só então descomissione a infraestrutura anterior. Outras práticas, como a arquitetura de unidade de escala, também são fundamentais.

As implementações de referência Mission-Critical Online e Azure Mission-Critical Connected ilustram essa abordagem de implantação, conforme mostrado neste diagrama:

Ambientes de aplicativos

Veja o vídeo a seguir para obter uma visão geral das recomendações para ambientes de aplicativos.

Você precisa de vários tipos de ambientes para validar e preparar operações de implantação. Os tipos têm diferentes capacidades e ciclos de vida. Alguns ambientes podem refletir o ambiente de produção e ser de longa duração, e outros podem ter vida curta e menos recursos do que a produção. A configuração desses ambientes no início do ciclo de desenvolvimento ajuda a garantir agilidade, separação de ativos de produção e pré-produção e testes completos das operações antes da liberação para o ambiente de produção. Todos os ambientes devem refletir o ambiente de produção tanto quanto possível, embora você possa aplicar simplificações a ambientes inferiores, conforme necessário. Este diagrama mostra uma arquitetura de missão crítica:

Existem algumas considerações comuns:

• Os componentes não devem ser compartilhados entre ambientes. Possíveis exceções são dispositivos de segurança downstream, como firewalls e locais de origem para dados de teste sintéticos.

• Todos os ambientes devem usar a infraestrutura como artefatos de código (IaC), como modelos Terraform ou Azure Resource Manager (ARM).

Ambientes de desenvolvimento

Veja o vídeo a seguir para obter informações sobre ambientes de desenvolvimento efêmeros e validação automatizada de recursos.

Considerações sobre o design

• Capacidades. Requisitos mais baixos de confiabilidade, capacidade e segurança são aceitáveis para ambientes de desenvolvimento.

• Ciclo de vida. Os ambientes de desenvolvimento devem ser criados conforme necessário e existir por um curto período de tempo. Ciclos de vida mais curtos ajudam a evitar desvios de configuração da base de código e reduzem custos. Além disso, os ambientes de desenvolvimento geralmente compartilham o ciclo de vida de um branch de recursos.

• Densidade. As equipes precisam de vários ambientes para dar suporte ao desenvolvimento paralelo de recursos. Eles podem coexistir em uma única assinatura.

Recomendações sobre design

• Mantenha o ambiente em uma assinatura dedicada com contexto definido para fins de desenvolvimento.

• Use um processo automatizado para implantar código de uma ramificação de recurso em um ambiente de desenvolvimento.

Ambientes de teste ou preparo

Esses ambientes são usados para teste e validação. Muitos ciclos de teste são realizados para garantir a implantação livre de bugs na produção. Os testes apropriados para uma carga de trabalho de missão crítica são descritos na seção Validação e teste contínuos.

Considerações sobre o design

• Capacidades. Esses ambientes devem refletir o ambiente de produção para confiabilidade, capacidade e segurança. Na ausência de uma carga de produção, use uma carga de usuário sintética para fornecer métricas realistas e valiosas entradas de modelagem de integridade.

• Ciclo de vida. Esses ambientes são de curta duração. Eles devem ser destruídos após a conclusão das validações de teste.

• Densidade. Você pode executar vários ambientes independentes em uma assinatura. Você também deve considerar o uso de vários ambientes, cada um em uma assinatura dedicada.

Observação

As aplicações de missão crítica devem ser submetidas a testes rigorosos.

Você pode executar diferentes funções de teste em um único ambiente e, em alguns casos, precisará. Por exemplo, para que o teste de caos forneça resultados significativos, você deve primeiro colocar o aplicativo sob carga para que possa entender como o aplicativo responde a falhas injetadas. É por isso que os testes de caos e de carga são normalmente realizados em paralelo.

Recomendações sobre design

• Certifique-se de que pelo menos um ambiente de preparo reflita totalmente a produção para permitir testes e validação semelhantes aos da produção. A capacidade nesse ambiente pode ser flexionada com base na execução de atividades de teste.

• Gere carga de usuário sintética para fornecer um caso de teste realista para alterações em um dos ambientes.

  Observação

  A implementação de referência do Mission Critical Online fornece um exemplo de um gerador de carga de usuário.

• Defina o número de ambientes de preparo e suas finalidades dentro do ciclo de desenvolvimento e lançamento.

Ambientes de produção

Considerações sobre o design

• Capacidades. Os mais altos níveis de confiabilidade, capacidade e funcionalidade de segurança para o aplicativo são necessários.

• Ciclo de vida. Embora o ciclo de vida da carga de trabalho e da infraestrutura permaneça o mesmo, todos os dados, incluindo monitoramento e registro, precisam de gerenciamento especial. Por exemplo, o gerenciamento é necessário para backup e recuperação.

• Densidade. Para alguns aplicativos, convém considerar o uso de diferentes ambientes de produção para atender a diferentes clientes, usuários ou funcionalidades de negócios.

Recomendações sobre design

Tenha um limite de governança claro para produção e ambientes inferiores. Coloque cada tipo de ambiente em uma assinatura dedicada para atingir esse objetivo. Essa segmentação garante que a utilização de recursos em ambientes mais baixos não afete as cotas de produção. As assinaturas dedicadas também definem limites de acesso.

Implantações azuis/verdes efêmeras

Um modelo de implantação azul/verde requer pelo menos duas implantações idênticas. A implantação azul é a ativa que atende ao tráfego de usuários em produção. A implantação verde é a nova que está preparada e testada para receber tráfego. Depois que a implantação verde é concluída e testada, o tráfego é gradualmente direcionado de azul para verde. Se a transferência de carga for bem-sucedida, a implantação verde se tornará a nova implantação ativa. A antiga implantação azul pode então ser descomissionada por meio de um processo em fases. No entanto, se houver problemas na nova implantação, ela poderá ser anulada e o tráfego poderá permanecer na implantação azul antiga ou ser redirecionado para ela.

A Missão Crítica do Azure recomenda uma abordagem de implantação azul/verde em que a infraestrutura e os aplicativos são implantados juntos como parte de um carimbo de implantação. Portanto, a implantação de uma alteração na infraestrutura ou no aplicativo sempre resulta em uma implantação verde que contém ambas as camadas. Essa abordagem permite testar e validar totalmente o efeito da alteração em relação à infraestrutura e ao aplicativo de ponta a ponta antes de redirecionar o tráfego do usuário para ela. A abordagem aumenta a confiança na liberação de alterações e permite atualizações de tempo de inatividade zero, pois as compatibilidades com dependências downstream, como a plataforma Azure, provedores de recursos e módulos IaC, podem ser validadas.

Considerações sobre o design

• Capacidades tecnológicas. Aproveite os recursos internos de implantação nos serviços do Azure. Por exemplo, o Serviço de Aplicativo do Azure fornece slots de implantação secundários que podem ser trocados após uma implantação. Com o Serviço de Kubernetes do Azure (AKS), você pode usar uma implantação de pod separada em cada nó e atualizar a definição de serviço.

• Duração da implantação. A implantação pode levar mais tempo para ser concluída porque o carimbo contém a infraestrutura e o aplicativo em vez de apenas o componente alterado. Isso, no entanto, é aceitável porque o risco de todos os componentes não funcionarem como esperado substitui as preocupações de tempo.

• Impacto nos custos. Há um custo adicional devido às duas implantações lado a lado, que devem coexistir até que a implantação seja concluída.

• Transição de tráfego. Depois que a nova implantação for validada, o tráfego deverá ser transferido do ambiente azul para o verde. Essa transição requer a orquestração do tráfego de usuários entre os ambientes. A transição deve ser totalmente automatizada.

• Ciclo de vida. Os carimbos de implantação de missão crítica devem ser considerados efêmeros. O uso de carimbos de curta duração cria um novo começo a cada vez, antes que os recursos sejam provisionados.

Recomendações sobre design

• Adote uma abordagem de implantação azul/verde para liberar todas as alterações de produção. Implante toda a infraestrutura e o aplicativo todas as vezes, para qualquer tipo de alteração, para obter um estado consistente e zero tempo de inatividade. Embora você possa reutilizar ambientes, não o recomendamos para cargas de trabalho de missão crítica. Trate cada carimbo de implantação regional como efêmero com um ciclo de vida vinculado ao de uma única versão.

• Use um balanceador de carga global, como o Azure Front Door, para orquestrar a transição automatizada do tráfego de usuários entre os ambientes azul e verde.

• Para fazer a transição de tráfego, adicione um ponto de extremidade de back-end verde que use um tráfego baixo para o peso do volume, como 10%. Depois de verificar se o baixo volume de tráfego na implantação verde funciona e fornece a integridade esperada do aplicativo, aumente gradualmente o tráfego. Ao fazer isso, aplique um curto período de ramp-up para detectar falhas que podem não ser imediatamente aparentes.

  Depois que todo o tráfego for transferido, remova o back-end azul das conexões existentes. Por exemplo, remova o back-end do serviço de balanceador de carga global, drene filas e desanexe outras associações. Isso ajuda a otimizar o custo de manutenção da infraestrutura de produção secundária e garantir que os novos ambientes estejam livres de desvios de configuração.

  Neste ponto, descomissione o antigo e agora inativo ambiente azul. Para a próxima implantação, repita o processo com azul e verde invertidos.

Implantação com escopo de assinatura

Dependendo dos requisitos de escala do seu aplicativo, talvez você precise de várias assinaturas de produção para servir como unidades de escala.

Assista ao vídeo a seguir para obter uma visão geral das recomendações para assinaturas de escopo para um aplicativo de missão crítica.

Considerações sobre o design

• Escalabilidade. Para cenários de aplicativos de alta escala com volumes significativos de tráfego, projete a solução para dimensionar em várias assinaturas do Azure para que os limites de escala de uma única assinatura não restrinjam a escalabilidade.

  Importante

  O uso de várias assinaturas requer complexidade adicional de CI/CD, que deve ser gerenciada adequadamente. Portanto, recomendamos várias assinaturas apenas em cenários de escala extrema, onde os limites de uma única assinatura provavelmente se tornarão uma limitação.

• Limites do ambiente. Implante ambientes de produção, desenvolvimento e teste em assinaturas separadas. Essa prática garante que ambientes mais baixos não contribuam para limites de escala. Ele também reduz o risco de atualizações de ambiente inferior poluindo a produção, fornecendo um gerenciamento claro e limites de identidade.

• Governança. Quando você precisar de várias assinaturas de produção, considere o uso de um grupo de gerenciamento de aplicativos dedicado para simplificar a atribuição de políticas por meio de um limite de agregação de políticas.

Recomendações sobre design

• Implante cada carimbo de implantação regional em uma assinatura dedicada para garantir que os limites de assinatura se apliquem somente no contexto de um único carimbo de implantação e não no aplicativo como um todo. Quando apropriado, você pode considerar o uso de vários carimbos de implantação em uma única região, mas deve implantá-los em assinaturas independentes.

• Coloque recursos compartilhados globais em uma assinatura dedicada para permitir a implantação consistente de assinatura regional. Evite usar uma implantação especializada para a região primária.

Validação e testes contínuos

O teste é uma atividade crítica que permite validar totalmente a integridade do código e da infraestrutura do aplicativo. Mais especificamente, o teste permite que você atenda aos seus padrões de confiabilidade, desempenho, disponibilidade, segurança, qualidade e escala. Os testes devem ser bem definidos e aplicados como parte do design do aplicativo e da estratégia de DevOps. O teste é uma preocupação fundamental durante o processo de desenvolvedor local (o loop interno) e como parte do ciclo de vida completo do DevOps (o loop externo), que é quando o código é iniciado no caminho dos processos de pipeline de lançamento para o ambiente de produção.

Assista ao vídeo a seguir para obter uma visão geral da validação e dos testes contínuos.

Esta seção se concentra no teste de loop externo. Descreve vários tipos de testes.

Teste	Descrição
Teste de unidade	Confirma que a lógica de negócios do aplicativo funciona conforme o esperado. Valida o efeito geral das alterações de código.
Teste de fumaça	Identifica se os componentes de infraestrutura e aplicativo estão disponíveis e funcionam conforme o esperado. Normalmente, apenas uma sessão de usuário virtual é testada. O resultado deve ser que o sistema responda com valores e comportamento esperados. Cenários comuns de teste de fumaça incluem alcançar o ponto de extremidade HTTPS de um aplicativo Web, consultar um banco de dados e simular um fluxo de usuário no aplicativo.
Teste de interface do usuário	Valida se as interfaces do usuário do aplicativo são implantadas e se as interações da interface do usuário funcionam conforme o esperado. Você deve usar ferramentas de automação da interface do usuário para impulsionar a automação. Durante um teste de interface do usuário, um script deve imitar um cenário de usuário realista e concluir uma série de etapas para executar ações e alcançar um resultado pretendido.
Teste de carga	Valida a escalabilidade e a operação do aplicativo aumentando a carga rapidamente e/ou gradualmente até que um limite predeterminado seja atingido. Normalmente, os testes de carga são projetados em torno de um fluxo de usuário específico para verificar se os requisitos do aplicativo são atendidos sob uma carga definida.
Teste de estresse	Aplica atividades que sobrecarregam os recursos existentes para determinar os limites da solução e verificar a capacidade do sistema de se recuperar normalmente. O principal objetivo é identificar possíveis gargalos de desempenho e limites de escala. Por outro lado, reduza os recursos de computação do sistema e monitore como ele se comporta sob carga e determine se ele pode se recuperar.
Testes de desempenho	Combina aspectos de testes de carga e estresse para validar o desempenho sob carga e estabelecer comportamentos de benchmark para a operação do aplicativo.
Testes de caos	Injeta falhas artificiais no sistema para avaliar como ele reage e validar a eficácia de medidas de resiliência, procedimentos operacionais e mitigações. O desligamento de componentes de infraestrutura, a degradação proposital do desempenho e a introdução de falhas de aplicativo são exemplos de testes que podem ser usados para verificar se o aplicativo reagirá conforme o esperado quando os cenários realmente ocorrerem.
Teste de penetração	Garante que um aplicativo e seu ambiente atendam aos requisitos de uma postura de segurança esperada. O objetivo é identificar vulnerabilidades de segurança. Os testes de segurança podem incluir a cadeia de suprimentos de software de ponta a ponta e dependências de pacotes, com varredura e monitoramento de vulnerabilidades e exposições comuns conhecidas (CVE).

Considerações sobre o design

• Automação. O teste automatizado é essencial para validar alterações de aplicativos ou infraestrutura de maneira oportuna e repetível.

• Ordem de teste. A ordem em que os testes são realizados é uma consideração crítica devido a várias dependências, como a necessidade de ter um ambiente de aplicativo em execução. A duração do teste também influencia a ordem. Testes com tempos de execução mais curtos devem ser executados mais cedo no ciclo, quando possível, para aumentar a eficiência do teste.

• Limites de escalabilidade. Os serviços do Azure têm limites flexíveis e rígidos diferentes. Considere o uso de testes de carga para determinar se um sistema corre o risco de excedê-los durante a carga de produção esperada. O teste de carga também pode ser útil para definir limites apropriados para dimensionamento automático. Para serviços que não oferecem suporte ao dimensionamento automático, o teste de carga pode ajudá-lo a ajustar os procedimentos operacionais automatizados.

  A incapacidade de componentes do sistema, como componentes de rede ativos/passivos ou bancos de dados, de dimensionar adequadamente pode ser restritiva. Os testes de esforço podem ajudar a identificar limitações.

• Análise do modo de falha. Introduzir falhas no aplicativo e na infraestrutura subjacente e avaliar o efeito é essencial para avaliar os mecanismos de redundância da solução. Durante essa análise, identifique o risco, o impacto e a amplitude do impacto (interrupção parcial ou total). Para obter um exemplo de análise criada para a implementação de referência do Mission Critical Online , consulte Riscos de interrupção de componentes individuais.

• Monitoramento. Você deve capturar e analisar os resultados do teste individualmente e também agregá-los para avaliar as tendências ao longo do tempo. Você deve avaliar continuamente os resultados do teste quanto à precisão e cobertura.

Recomendações sobre design

Veja o vídeo a seguir para ver como o teste de resiliência pode ser integrado aos pipelines de CI/CD do Azure DevOps.

• Garanta a consistência automatizando todos os testes em componentes de infraestrutura e aplicativos. Integre os testes em pipelines de CI/CD para orquestrar e executá-los quando aplicável. Para obter informações sobre opções de tecnologia, consulte Ferramentas de DevOps.

• Trate todos os artefatos de teste como código. Eles devem ser mantidos e controlados por versão junto com outros artefatos de código de aplicativo.

• Alinhe o SLA da infraestrutura de teste com o SLA para ciclos de implantação e teste.

• Execute testes de fumaça como parte de cada implantação. Também execute testes de carga extensivos juntamente com testes de estresse e caos para validar se o desempenho e a operabilidade do aplicativo são mantidos.

  • Use perfis de carga que reflitam padrões reais de pico de uso.
  • Execute experimentos de caos e testes de injeção de falhas ao mesmo tempo que testes de carga.

  Dica

  O Azure Chaos Studio é um conjunto nativo de ferramentas de experimentação de caos. As ferramentas facilitam a realização de experimentos de caos e a injeção de falhas nos serviços e componentes de aplicativos do Azure.

  O Chaos Studio fornece experimentos internos de caos para cenários de falha comuns e oferece suporte a experimentos personalizados que visam componentes de infraestrutura e aplicativos.

• Se interações de banco de dados, como a criação de registros, forem necessárias para testes de carga ou fumaça, use contas de teste que tenham privilégios reduzidos e torne os dados de teste separáveis do conteúdo real do usuário.

• Examine e monitore a cadeia de suprimentos de software de ponta a ponta e as dependências de pacote para CVEs conhecidos.

  • Use o Dependabot para repositórios GitHub para garantir que o repositório esteja automaticamente atualizado com as versões mais recentes de pacotes e aplicativos dos quais ele depende.

Infraestrutura como implantações de código

Infraestrutura como código (IaC) trata as definições de infraestrutura como código-fonte que é controlado por versão junto com outros artefatos de aplicativo. O uso do IaC promove a consistência do código em todos os ambientes, elimina o risco de erro humano durante implantações automatizadas e fornece rastreabilidade e reversão. Para implantações azuis/verdes, o uso de IaC com implantações totalmente automatizadas é imprescindível.

Um repositório IaC de missão crítica tem duas definições distintas que são mapeadas para recursos globais e regionais. Para obter informações sobre esses tipos de recursos, consulte o padrão de arquitetura principal.

Considerações sobre o design

• Infraestrutura repetível. Implante cargas de trabalho de missão crítica de uma forma que gere sempre o mesmo ambiente. O IaC deve ser o modelo primário.

• Automação. Todas as implantações devem ser totalmente automatizadas. Os processos humanos são propensos a erros.

Recomendações sobre design

• Aplique IaC, garantindo que todos os recursos do Azure sejam definidos em modelos declarativos e mantidos em um repositório de controle de origem. Os modelos são implantados e os recursos são provisionados automaticamente a partir do controle do código-fonte por meio de pipelines de CI/CD. Não recomendamos o uso de scripts imperativos.

• Proibir operações manuais em todos os ambientes. A única exceção são os ambientes de desenvolvedor totalmente independentes.

Ferramentas DevOps

O uso efetivo das ferramentas de implantação é fundamental para a confiabilidade geral porque os processos de DevOps afetam a função geral e o design do aplicativo. Por exemplo, as operações de failover e dimensionamento podem depender da automação fornecida pelas ferramentas de DevOps. As equipes de engenharia devem entender o efeito da indisponibilidade de um serviço de implantação em relação à carga de trabalho geral. As ferramentas de implantação devem ser confiáveis e altamente disponíveis.

A Microsoft fornece dois conjuntos de ferramentas nativos do Azure, GitHub Actions e Azure Pipelines, que podem implantar e gerenciar com eficiência um aplicativo de missão crítica.

Considerações sobre o design

• Capacidades tecnológicas. Os recursos do GitHub e do Azure DevOps se sobrepõem. Você pode usá-los juntos para obter o melhor de ambos. Uma abordagem comum é armazenar repositórios de código no GitHub.com ou no GitHub AE ao usar o Azure Pipelines para implantação.

  Esteja ciente da complexidade que é adicionada quando você usa várias tecnologias. Avalie um conjunto avançado de recursos em relação à confiabilidade geral.

• Disponibilidade regional. Em termos de confiabilidade máxima, a dependência de uma única região do Azure representa um risco operacional.

  Por exemplo, digamos que o tráfego esteja espalhado por duas regiões: Região 1 e Região 2. A Região 2 hospeda a instância de ferramentas de DevOps do Azure. Suponha que haja uma interrupção na Região 2 e a instância não esteja disponível. A Região 1 lida automaticamente com todo o tráfego e precisa implantar unidades de escala extra para fornecer uma boa experiência de failover. Mas ele não será capaz devido à dependência do Azure DevOps na Região 2.

• Replicação de dados. Os dados, incluindo metadados, pipelines e código-fonte, devem ser replicados entre regiões.

Recomendações sobre design

• Ambas as tecnologias são hospedadas em uma única região do Azure, o que pode tornar sua estratégia de recuperação de desastres restritiva.

  O GitHub Actions é adequado para tarefas de compilação (integração contínua), mas pode faltar recursos para tarefas de implantação complexas (implantação contínua). Dado o rico conjunto de recursos do Azure DevOps, recomendamos que ele seja para implantações de missão crítica. No entanto, você deve fazer uma escolha depois de avaliar as compensações.

• Defina um SLA de disponibilidade para ferramentas de implantação e garanta o alinhamento com requisitos mais amplos de confiabilidade de aplicativos.

• Para cenários de várias regiões que usam uma configuração de implantação ativa/passiva ou ativa/ativa, verifique se as operações de orquestração e dimensionamento de failover podem continuar a funcionar mesmo se os conjuntos de ferramentas de implantação da região primária que hospedam ficarem indisponíveis.

Estratégia de ramificação

Existem muitas abordagens válidas para a ramificação. Você deve escolher uma estratégia que garanta a máxima confiabilidade. Uma boa estratégia permite o desenvolvimento paralelo, fornece um caminho claro do desenvolvimento à produção e suporta lançamentos rápidos.

Considerações sobre o design

• Minimizar o acesso. Os desenvolvedores devem fazer seu trabalho em feature/* e fix/* filiais. Essas ramificações se tornam pontos de entrada para alterações. As restrições baseadas em função devem ser aplicadas às ramificações como parte da estratégia de ramificação. Por exemplo, permita que os administradores criem ramificações de liberação ou imponham convenções de nomenclatura para ramificações.

• Processo acelerado para emergências. A estratégia de ramificação deve permitir que os hotfixes sejam mesclados assim main que possível. Dessa forma, versões futuras contêm a correção e a recorrência do problema é evitada. Use esse processo apenas para pequenas alterações que resolvam problemas urgentes e use-o com moderação.

Recomendações sobre design

• Priorize o uso do GitHub para controle do código-fonte.

  Importante

  Crie uma estratégia de ramificação que detalhe o trabalho e as versões de recursos como um mínimo e use diretivas e permissões de ramificação para garantir que a estratégia seja aplicada adequadamente.

• Acione um processo de teste automatizado para validar as contribuições de alteração de código antes que elas sejam aceitas. Os membros da equipe também devem revisar as alterações.

• Trate a main ramificação como uma ramificação continuamente avançada e estável que é usada principalmente para testes de integração.

  • Certifique-se de main que as alterações sejam feitas somente por meio de RPs. Use uma política de ramificação para proibir confirmações diretas.
  • Toda vez que um PR é mesclado no main, ele deve iniciar automaticamente uma implantação em um ambiente de integração.
  • O main ramo deve ser considerado estável. Deve ser seguro criar uma liberação a partir de main um determinado momento.

• Use ramificações dedicadas release/* que são criadas a main partir da ramificação e usadas para implantar em ambientes de produção. release/* ramificações devem permanecer no repositório e podem ser usadas para corrigir uma versão.

• Documente um processo de hotfix e use-o somente quando necessário. Crie hotfixes em uma fix/* ramificação para mesclagem subsequente na ramificação de lançamento e implantação em produção.

IA para DevOps

Você pode aplicar metodologias AIOps em pipelines de CI/CD para complementar as abordagens de teste tradicionais. Isso permite a detecção de possíveis regressões ou degradações e permite que as implantações sejam interrompidas preventivamente para evitar possíveis impactos negativos.

Considerações sobre o design

• Volume de dados de telemetria. Os pipelines de CI/CD e os processos de DevOps emitem uma ampla variedade de telemetria para modelos de aprendizado de máquina. A telemetria varia de resultados de teste e resultados de implantação a dados operacionais sobre componentes de teste de estágios de implantação compostos.

• Escalabilidade. As abordagens tradicionais de processamento de dados, como Extrair, Transformar, Carregar (ETL), podem não ser capazes de dimensionar a taxa de transferência para acompanhar o crescimento da telemetria de implantação e dos dados de observabilidade do aplicativo. Você pode usar abordagens de análise modernas que não exigem ETL e movimentação de dados, como virtualização de dados, para permitir a análise contínua por modelos AIOps.

• Alterações de implantação. As alterações na implantação precisam ser armazenadas para análise automatizada e correlação com os resultados da implantação.

Recomendações sobre design

• Defina os dados de processo de DevOps a serem coletados e como analisá-los. A telemetria, como métricas de execução de teste e dados de séries temporais de alterações dentro de cada implantação, é importante.

  • Exponha dados de observabilidade de aplicativos de ambientes de preparação, teste e produção para análise e correlação em modelos AIOps.

• Adote o fluxo de trabalho MLOps.

• Desenvolva modelos analíticos com reconhecimento de contexto e dependência para fornecer previsões com engenharia de recursos automatizada para lidar com alterações de esquema e comportamento.

• Operacionalize modelos registrando e implantando os modelos mais bem treinados dentro dos pipelines de implantação.

Próxima etapa

Revise as considerações de segurança.

Segurança