Implantação e teste para cargas de trabalho de missão crítica no Azure

Implantações com falha e versões incorretas são causas comuns de interrupçõ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, a fim de 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 diferentes ambientes. A automação de ponta a ponta é obrigatória. As intervenções manuais devem ser evitadas porque podem introduzir riscos de fiabilidade.

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 dos aplicativos.

Importante

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

Implantação sem tempo de inatividade

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

Alcançar implantações sem tempo de inatividade é 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-chave de design, como tratar os recursos como efêmeros.

Para alcançar a implantação sem tempo de inatividade, implante uma nova infraestrutura ao lado da infraestrutura existente, teste-a minuciosamente, 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 unidades 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 aplicação

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 ser de curta duração e ter 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 dos 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 mais baixos, 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 artefatos de infraestrutura como 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 de 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 uma ramificação de recurso.

• Densidade. As equipes precisam de vários ambientes para dar suporte ao desenvolvimento paralelo de recursos. Podem coexistir numa única subscrição.

Recomendações de 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 para 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 de 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 informações valiosas de modelagem de integridade.

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

• 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.

Nota

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, será necessário. Por exemplo, para que o teste de caos forneça resultados significativos, você deve primeiro colocar o aplicativo sob carga para entender como o aplicativo responde a falhas injetadas. É por isso que o teste de caos e o teste de carga são normalmente realizados em paralelo.

Recomendações de 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 dentro desse 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.

  Nota

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

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

Ambientes de produção

Considerações de design

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

• 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 de design

Ter 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 subscrições dedicadas também definem limites de acesso.

Implantações efêmeras azuis/verdes

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 na 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 desativada por meio de um processo em fases. No entanto, se houver problemas na nova implantação, ela pode ser abortada e o tráfego pode permanecer na implantação azul antiga ou ser redirecionado para ela.

O Azure Mission-Critical 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, implementar uma alteração na infraestrutura ou no aplicativo sempre resulta em uma implantação verde que contém ambas as camadas. Essa abordagem permite que você teste e valide totalmente o efeito da alteração em relação à infraestrutura e ao aplicativo de ponta a ponta antes de redirecionar o tráfego de usuários para ela. A abordagem aumenta a confiança na liberação de alterações e permite atualizações sem tempo de inatividade porque as compatibilidades com dependências downstream, como a plataforma Azure, provedores de recursos e módulos IaC, podem ser validadas.

Considerações de design

• Capacidades tecnológicas. Aproveite os recursos de implantação internos 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 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. No entanto, isto é aceitável porque o risco de todos os componentes não funcionarem como esperado sobrepõe-se às preocupações com o 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 deve 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 selos 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 de 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 sempre, para qualquer tipo de alteração, para obter um estado consistente e zero tempo de inatividade. Embora você possa reutilizar ambientes, não recomendamos isso para cargas de trabalho de missão crítica. Trate cada selo 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 back-end verde que use um tráfego baixo para peso de 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 detetar 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 garante 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, você pode precisar de várias assinaturas de produção para servir como unidades de escala.

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

Considerações de design

• Escalabilidade. Para cenários de aplicativos de alta escala com volumes significativos de tráfego, projete a solução para escalar 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 ambientais. 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. Também reduz o risco de atualizações ambientais mais baixas poluindo a produção, fornecendo um gerenciamento claro e limites de identidade.

• Governação. Quando precisar de várias assinaturas de produção, considere usar 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 de 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 em todo o aplicativo. 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 assinaturas regionais. 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, os testes permitem 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 do desenvolvedor local (o loop interno) e como parte do ciclo de vida completo do DevOps (o loop externo), que é quando o código começa no caminho dos processos de pipeline de liberação para o ambiente de produção.

Veja o 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	Description
Testes unitários	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 a infraestrutura e os componentes do aplicativo estão disponíveis e funcionam conforme o esperado. Normalmente, apenas uma única sessão de usuário virtual é testada. O resultado deve ser que o sistema responda com valores e comportamento esperados. Os 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 o resultado pretendido.
Testes 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. Os testes de carga geralmente 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.
Testes de esforço	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 potenciais 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.
Teste de desempenho	Combina aspetos de testes de carga e esforço para validar o desempenho sob carga e estabelecer comportamentos de referência para a operação do aplicativo.
Teste 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 no 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.
Testes 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 dependências de pacotes e cadeia de suprimento de software de ponta a ponta, com verificação e monitoramento de vulnerabilidades e exposições comuns conhecidas (CVE).

Considerações de design

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

• Ordem de teste. A ordem na qual os testes são conduzidos é 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 diferentes limites flexíveis e rígidos. 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 dos 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. A introdução de falhas no aplicativo e na infraestrutura subjacente e a avaliação do efeito são essenciais 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 que foi criada para a implementação de referência do Mission Critical Online , consulte Riscos de interrupção de componentes individuais.

• Monitorização. 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 dos testes quanto à precisão e cobertura.

Recomendações de design

Veja o vídeo seguinte para ver como os testes de resiliência podem ser integrados com 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 a versão controlada 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. Execute também 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.

  Gorjeta

  O Azure Chaos Studio é um conjunto nativo de ferramentas de experimentação do 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 de caos integrados para cenários de falha comuns e oferece suporte a experimentos personalizados que visam a infraestrutura e os componentes do aplicativo.

• 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 tornem os dados de teste separáveis do conteúdo real do usuário.

• Analise e monitore a cadeia de suprimentos de software de ponta a ponta e as dependências de pacotes em busca de CVEs conhecidos.

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

Infraestrutura como implantações de código

Infraestrutura como código (IaC) trata as definições de infraestrutura como código-fonte cuja versão é controlada juntamente com outros artefatos de aplicativo. O uso do IaC promove a consistência do código entre 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 é imperativo.

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 de design

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

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

Recomendações de design

• Aplique o IaC, garantindo que todos os recursos do Azure sejam definidos em modelos declarativos e mantidos em um repositório de controle do código-fonte. 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 desenvolvedores 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 efetivamente um aplicativo de missão crítica.

Considerações de 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 enquanto usa 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 está distribuído por duas regiões: Região 1 e Região 2. A Região 2 hospeda a instância de ferramentas do Azure DevOps. 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 não será possível 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 de 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 não ter recursos para tarefas de implantação complexas (implantação contínua). Dado o rico conjunto de recursos do Azure DevOps, recomendamos isso 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 do aplicativo.

• Para cenários de várias regiões que usam uma configuração de implantação ativa/passiva ou ativa/ativa, certifique-se de que as operações de orquestração e dimensionamento de failover possam continuar a funcionar mesmo se a região primária que hospeda conjuntos de ferramentas de implantação ficar indisponível.

Estratégia de ramificação

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

Considerações de design

• Minimize o acesso. Os desenvolvedores devem fazer seu trabalho em feature/* e fix/* filiais. Estas sucursais tornam-se pontos de entrada para alterações. As restrições baseadas na função devem ser aplicadas às sucursais 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 fundidos o main mais rápido possível. Dessa forma, versões futuras contêm a correção e a recorrência do problema é evitada. Use este processo apenas para pequenas alterações que resolvam problemas urgentes e use-o com moderação.

Recomendações de 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 políticas e permissões de ramificação para garantir que a estratégia seja aplicada adequadamente.

• Acione um processo de teste automatizado para validar 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 estável e em movimento contínuo que é usada principalmente para testes de integração.

  • Certifique-se de main que as alterações são feitas apenas através de RPs. Use uma política de filial para proibir confirmações diretas.
  • Sempre que um RP é 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 qualquer main 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/* As 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 posterior mesclagem na ramificação de versão e implantação na produção.

IA para DevOps

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

Considerações de 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 na 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 de design

• Defina os dados de processo de DevOps a serem coletados e como analisá-los. A telemetria, como métricas de execução de testes 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 sensíveis ao 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 em pipelines de implantação.

Próximo passo

Analise as considerações de segurança.

Segurança