Práticas de implantação seguras

Às vezes, um lançamento não corresponde às expectativas. Apesar de usar as melhores práticas e passar todas as portas de qualidade, ocasionalmente há problemas que resultam em uma implantação de produção causando problemas imprevistos para os usuários. Para minimizar e mitigar o impacto desses problemas, as equipes de DevOps são incentivadas a adotar uma estratégia de exposição progressiva que equilibre a exposição de uma determinada versão com seu desempenho comprovado. À medida que um lançamento se prova em produção, ele fica disponível para níveis de público mais amplo até que todos estejam usando. As equipes podem usar práticas de implantação seguras para maximizar a qualidade e a velocidade das liberaçõ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 das atualizações aos clientes. Historicamente, o teste A/B tem sido uma escolha popular para equipes que procuram ver como diferentes versões de um serviço ou interface do usuário se comportam em relação aos objetivos alvo. O teste A/B também é relativamente fácil de usar, uma vez que as alterações são normalmente menores e, muitas vezes, só comparam versões diferentes na borda de um serviço voltada para o cliente.

Implantação segura por meio de camadas

À medida que as plataformas crescem, a escala da infraestrutura e as necessidades do público tendem a crescer também. Isso cria uma demanda por um modelo de implantação que equilibre os riscos associados a uma nova implantação com os benefícios das atualizações prometidas. A ideia geral é que uma determinada libertação deve ser primeiro exposta apenas a um pequeno grupo de utilizadores com maior tolerância ao risco. 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 pode continuar através de grupos mais amplos de usuários, ou camadas, até que todos estejam usando a nova versão. Com plataformas modernas de entrega contínua , como GitHub Actions e Azure Pipelines, a criação de um processo de implantação com camadas é acessível a equipes de DevOps de qualquer tamanho.

Marcas de funcionalidades

Certas funcionalidades às vezes precisam ser implantadas como parte de uma versão, mas não são inicialmente expostas 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 utilizador

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

Práticas múltiplas são comumente 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 de um usuário optar por usar o novo recurso. Qualquer pessoa que não esteja na camada, nessa implantação ou não tenha optado por participar não será exposta ao recurso. Embora este seja um exemplo bastante inventado, serve para ilustrar a flexibilidade e a praticidade da exposição progressiva.

Problemas comuns que as equipas enfrentam desde cedo

À medida que as equipes avançam para uma prática de DevOps mais ágil, elas podem encontrar problemas consistentes com outras que migraram das entregas monolíticas tradicionais. As equipes acostumadas a implantar uma vez a cada poucos meses têm uma mentalidade que protege para a estabilização. Eles esperam que cada implantação introduza uma mudança substancial em seu serviço e que haja problemas imprevistos.

As cargas úteis são demasiado grandes

Os serviços que são 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á muitas coisas novas. Ao mudar 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.

Sem isolamento de serviço

Os sistemas monolíticos são tradicionalmente dimensionados pelo nivelamento do hardware no qual são implantados. No entanto, quando algo corre mal com o caso, 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, já que muitos sistemas legados 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 podem ser melhor consolidadas em outro lugar.

À 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 do serviço.

Passos manuais levam a erros

Quando uma equipe implanta apenas algumas vezes por ano, automatizar as entregas pode não 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 compilação e implantação mais comuns pode ajudar muito a reduzir o tempo perdido e os erros não forçados.

As equipes também podem usar a infraestrutura como código para ter um melhor controle sobre os ambientes de implantação. Isso elimina 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 o Ops pode 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 de DevOps Ágil se beneficia muito quando a equipe de desenvolvimento pode iniciar e controlar implantações. As modernas plataformas de entrega contínua oferecem controle granular sobre quem pode iniciar quais implantações e quem pode acessar logs de status e outras informações de diagnóstico, garantindo que as pessoas certas tenham as informações certas o mais rápido possível.

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

Às vezes, uma implantação dá errado e as equipes precisam lidar com isso. 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, existem várias ferramentas e práticas para reduzir o risco de falhas nas implantações.

Princípios fundamentais

As equipas que procuram adotar práticas de implementação seguras devem definir alguns princípios fundamentais para apoiar o esforço.

Seja consistente

As mesmas ferramentas usadas para implantar na 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 detetados bem antes do código estar perto de ser liberado para produção.

Cuidado com os sinais de qualidade

Muitas equipas caem na armadilha comum de não se preocuparem realmente com os sinais de qualidade. Com o tempo, eles podem descobrir que escrevem testes ou assumem tarefas de qualidade simplesmente para mudar um aviso amarelo para uma aprovação verde. Os 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 monitorados constantemente todos os dias.

As implantações devem exigir tempo de inatividade zero

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

As implantações devem acontecer 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. Além disso, torna-se vantajoso empurrar implantações durante o horário de trabalho, especialmente no início do dia e no início da semana. Se algo correr mal, deve ser rastreado com antecedência suficiente para controlar o raio de 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 maduras de lançamento de DevOps estão em posição de assumir a implantação baseada em camadas. Neste modelo, novos recursos são lançados primeiro para clientes dispostos a aceitar o maior risco. À medida que a implantação é comprovada, o público se expande para incluir mais usuários até que todos estejam usando.

Um modelo de camada de exemplo

Um modelo típico de implantação de camada é 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 assar

O termo bake time refere-se à quantidade de tempo que uma implantação pode ser executada antes de expandir para a próxima camada. Alguns problemas podem levar horas ou mais para começar a mostrar sintomas, então a liberação deve estar em uso por um período apropriado de tempo 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 picam durante o horário comercial.

Agilizar hotfixes

Um incidente no local ao vivo (LSI) 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 pode 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 perturbadores que devem ser resolvidos imediatamente.

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

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

Principais conclusões

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

• Implante com frequência.
• Mantenha-se verde durante todo o sprint.
• Use ferramentas de implantação consistentes no desenvolvimento, teste e produção.
• Utilize uma plataforma de entrega contínua que permita automação e autorização.
• Siga práticas de implantação seguras.

Próximos passos

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