Práticas de implantação seguras

Às vezes, uma versão não corresponde às expectativas. Apesar de usar as práticas recomendadas e passar todos os portões de qualidade, ocasionalmente há problemas que resultam em uma implantação de produção causando problemas imprevistos para os usuários. Para minimizar e atenuar o impacto desses problemas, as equipes do DevOps são incentivadas a adotar uma estratégia de exposição progressiva que equilibra a exposição de uma determinada versão com seu desempenho comprovado. À medida que um lançamento se mostra em produção, ele se torna disponível para camadas de públicos mais amplos até que todos estejam usando-o. O Teams pode usar práticas de implantação seguras para maximizar a qualidade e a velocidade das versões em produção.

Controlar a exposição aos clientes

As equipes de DevOps podem empregar várias práticas para controlar a exposição de atualizações aos clientes. Historicamente, o teste A/B tem sido uma opção popular para as equipes que procuram ver como diferentes versões de um serviço ou interface do usuário são executadas em relação às metas de destino. O teste A/B também é relativamente fácil de usar, pois as alterações normalmente são secundárias e geralmente só comparam versões diferentes na borda voltada para o cliente de um serviço.

Implantação segura por meio de camadas

À medida que as plataformas crescem, a escala de infraestrutura e o público-alvo tendem a crescer também. Isso cria uma demanda por um modelo de implantação que equilibra os riscos associados a uma nova implantação com os benefícios das atualizações que promete. A ideia geral é que uma determinada versão deve ser exposta primeiro apenas a um pequeno grupo de usuários com maior tolerância a riscos. Em seguida, se a versão funcionar conforme o esperado, ela poderá ser exposta a um grupo mais amplo de usuários. Se não houver problemas, o processo poderá continuar por meio de grupos mais amplos de usuários ou camadas, até que todos estejam usando a nova versão. Com plataformas de entrega contínua modernas, como o GitHub Actions e o Azure Pipelines, a criação de um processo de implantação com camadas é acessível para equipes de DevOps de qualquer tamanho.

Sinalizadores de recursos

Algumas funcionalidades às vezes precisam ser implantadas como parte de uma versão, mas não expostas inicialmente aos usuários. Nesses casos, os sinalizadores de recursos fornecem uma solução em que a funcionalidade pode ser habilitada por meio de alterações de configuração com base no ambiente, na camada ou em qualquer outra implantação específica.

Aceitação do usuário

Semelhante aos sinalizadores de recursos, a aceitação do usuário fornece uma maneira de limitar a exposição. Nesse modelo, um determinado recurso é habilitado na versão, mas não é ativado para um usuário, a menos que ele o queira especificamente. A decisão de tolerância a riscos é descarregada para os usuários para que eles possam decidir a rapidez com que desejam adotar determinadas atualizações.

Várias práticas geralmente são empregadas simultaneamente. Por exemplo, uma equipe pode ter um recurso experimental destinado a um caso de uso muito específico. Como é arriscado, eles o implantarão na primeira camada para que os usuários internos experimentem. No entanto, mesmo que os recursos estejam no código, alguém precisará definir o sinalizador de recurso para uma implantação específica dentro da camada para que o recurso seja exposto por meio da interface do usuário. Mesmo assim, o sinalizador de recurso só pode expor a opção para um usuário aceitar o uso do novo recurso. Qualquer pessoa que não esteja na camada, nessa implantação ou não tenha optado não será exposta ao recurso. Embora este seja um exemplo bastante inventado, ele serve para ilustrar a flexibilidade e a praticidade da exposição progressiva.

Problemas comuns que as equipes enfrentam no início

À medida que as equipes se movem em direção a uma prática mais Agile DevOps, elas podem encontrar problemas consistentes com outras pessoas que migraram para longe das entregas monolíticas tradicionais. As equipes usadas para implantar uma vez a cada poucos meses têm uma mentalidade que faz buffers para estabilização. Eles esperam que cada implantação introduza uma mudança substancial em seu serviço e que haverá problemas imprevistos.

Os conteúdos são muito grandes

Os serviços implantados a cada poucos meses geralmente são preenchidos com muitas alterações. Isso aumenta a probabilidade de haver problemas imediatos e também dificulta a solução desses problemas, já que há tanta coisa nova. Ao migrar para entregas mais frequentes, as diferenças no que é implantado se tornam menores, o que permite testes mais focados e depuração mais fácil.

Nenhum isolamento de serviço

Sistemas monolíticos são tradicionalmente dimensionados nivelando o hardware no qual são implantados. No entanto, quando algo dá errado com a instância, isso leva a problemas para todos. Uma solução simples é adicionar várias instâncias para que você possa balancear a carga dos usuários. No entanto, isso pode exigir considerações arquitetônicas significativas, pois muitos sistemas herdados não são criados para serem de várias instâncias. Além disso, recursos duplicados significativos podem precisar ser alocados para funcionalidades que possam ser melhor consolidadas em outros lugares.

À medida que novos recursos são adicionados, explore se uma arquitetura de microsserviços pode ajudá-lo a operar e dimensionar graças a um melhor isolamento de serviço.

Etapas manuais levam a erros

Quando uma equipe implanta apenas algumas vezes por ano, a automatização de entregas pode não parecer valer a pena o investimento. Como resultado, muitos processos de implantação são gerenciados manualmente. Isso requer uma quantidade significativa de tempo e esforço e é propenso a erros humanos. Simplesmente automatizar as tarefas de build e implantação mais comuns pode percorrer um longo caminho para reduzir o tempo perdido e erros não forçados.

O Teams também pode usar a infraestrutura como código para ter melhor controle sobre os ambientes de implantação. Isso remove a necessidade de solicitações à equipe de operações para fazer alterações manuais à medida que novos recursos ou dependências são introduzidos em vários ambientes de implantação.

Somente operações podem fazer implantações

Algumas organizações têm políticas que exigem que todas as implantações sejam iniciadas e gerenciadas pela equipe de operações. Embora possa ter havido boas razões para isso no passado, um processo agile DevOps se beneficia muito quando a equipe de desenvolvimento pode iniciar e controlar implantações. As plataformas de entrega contínua modernas oferecem controle granular sobre quem pode iniciar quais implantações e quem pode acessar logs de status e outras informações de diagnóstico, certificando-se de que as pessoas certas tenham as informações certas o mais rápido possível.

Implantações incorretas prossseguem e não podem ser revertidas

Às vezes, uma implantação dá errado e as equipes precisam resolvê-la. No entanto, quando os processos são manuais e o acesso às informações é lento e limitado, pode ser difícil reverter para uma implantação de trabalho anterior. Felizmente, há várias ferramentas e práticas para atenuar o risco de implantações com falha.

Princípios fundamentais

As equipes que buscam adotar práticas de implantação seguras devem definir alguns princípios fundamentais para sustentar o esforço.

Ser consistente

As mesmas ferramentas usadas para implantar em produção devem ser usadas em ambientes de desenvolvimento e teste. Se houver problemas, como os que geralmente surgem de novas versões de dependências ou ferramentas, eles devem ser capturados bem antes que o código esteja próximo de ser liberado para produção.

Cuidado com sinais de qualidade

Muitas equipes caem na armadilha comum de não se importar com sinais de qualidade. Com o tempo, eles podem descobrir que escrevem testes ou assumem tarefas de qualidade simplesmente para alterar um aviso amarelo para uma aprovação verde. Sinais de qualidade são realmente importantes, pois representam o pulso de um projeto. Os sinais de qualidade usados para aprovar implantações devem ser acompanhados constantemente todos os dias.

As implantações devem exigir tempo de inatividade zero

Embora não seja essencial que todos os serviços estejam sempre disponíveis, as equipes devem abordar seus estágios de entrega e operação do DevOps com a mentalidade de que podem e devem implantar novas versões sem precisar retirá-las a qualquer momento. A infraestrutura moderna e as ferramentas de pipeline são avançadas o suficiente agora, onde é viável para praticamente qualquer equipe atingir 100% tempo de atividade.

As implantações devem ocorrer durante o horário de trabalho

Se uma equipe trabalha com a mentalidade de que as implantações exigem tempo de inatividade zero, isso realmente não importa quando uma implantação é enviada por push. Além disso, torna-se vantajoso enviar implantações por push durante o horário de trabalho, especialmente no início do dia e no início da semana. Se algo der errado, deve ser rastreado cedo o suficiente para controlar o raio da explosão. Além disso, todos já estarão trabalhando e focados em corrigir problemas.

Implantação baseada em camadas

As equipes com práticas de versão de DevOps maduras estão em posição de assumir a implantação baseada em camadas. Nesse modelo, os novos recursos são lançados pela primeira vez para clientes dispostos a aceitar o maior risco. Como a implantação é comprovada, o público-alvo se expande para incluir mais usuários até que todos estejam usando-a.

Um modelo de camada de exemplo

Um modelo de implantação de camada típico foi projetado para encontrar problemas o mais cedo possível por meio da segmentação cuidadosa de usuários e infraestrutura. O exemplo a seguir mostra como as camadas são usadas por uma equipe principal da Microsoft.

Permitir tempo de cozimento

O termo bake time refere-se à quantidade de tempo que uma implantação tem permissão para ser executada antes de expandir para a próxima camada. Alguns problemas podem levar horas ou mais para começar a apresentar sintomas, portanto, a liberação deve estar em uso por um período apropriado antes de ser considerada pronta.

Em geral, um dia de 24 horas deve ser tempo suficiente para a maioria dos cenários expor bugs latentes. No entanto, esse período deve incluir um período de pico de uso, exigindo um dia útil completo, para serviços que atingem o pico durante o horário comercial.

Agilizar hotfixes

Um LSI (incidente de site ao vivo ) ocorre quando um bug tem um impacto sério na produção. As LSIs exigem a criação de um hotfix, que é uma atualização fora de banda projetada para resolver um problema de alta prioridade.

Se um bug for Sev 0, o tipo mais grave de bug, o hotfix poderá ser implantado diretamente na unidade de escala afetada o mais rápido possível. Embora seja fundamental que a correção não piore as coisas, bugs dessa gravidade são considerados tão disruptivos que devem ser resolvidos imediatamente.

Os bugs classificados como Sev 1 devem ser implantados por meio da camada 0, mas podem ser implantados nas unidades de escala afetadas assim que aprovados.

Os hotfixes para bugs com gravidade inferior devem ser implantados em todas as camadas conforme planejado.

Principais conclusões

Cada equipe deseja fornecer atualizações rapidamente e com a mais alta qualidade possível. Com as práticas corretas, a entrega pode ser uma parte produtiva e indolor do ciclo de DevOps.

• Implante com frequência.
• Fique verde durante toda a corrida.
• Use ferramentas de implantação consistentes em desenvolvimento, teste e produção.
• Use uma plataforma de entrega contínua que permita automação e autorização.
• Siga as práticas de implantação seguras.

Próximas etapas

Saiba como os sinalizadores de recursos ajudam a controlar a exposição de novos recursos aos usuários.