Práticas de implantação segura

Às vezes, um lançamento não corresponde às expectativas. Apesar de usar as práticas recomendadas e passar por todos os controles de qualidade, ocasionalmente há questões que resultam em uma implantação de produção que causa problemas imprevistos para os usuários. Para minimizar e mitigar o impacto desses problemas, as equipes do DevOps são incentivadas a adotar uma estratégia de exposição progressiva que equilibre a exposição de certa versão com desempenho comprovado. Quando uma versão entra em produção, ela fica disponível para níveis de públicos-alvos mais amplos até que todos a utilizem. As equipes podem usar práticas de implantação seguras para maximizar a qualidade e a velocidade dos lançamentos em produção.

Controle a exposição a clientes

As equipes do DevOps podem empregar várias práticas para controlar a exposição de atualizações a clientes. Historicamente, o teste A/B tem sido uma escolha popular para equipes que desejam saber como versões distintas de um serviço ou interface do usuário se comportam em relação às metas de destino. O teste A/B também é relativamente fácil de usar porque as alterações costumam ser menores e frequentemente só comparam versões distintas na borda voltada ao cliente de um serviço.

Implantação segura por anéis

À medida que as plataformas crescem, a escala da infraestrutura e as necessidades do público-alvo tendem a crescer. Isso gera 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 é primeiro expor uma versão específica apenas a um grupo reduzido de usuários com a maior tolerância ao risco. 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 anéis, até que todos usem a nova versão. Com plataformas modernas de entrega contínua como o GitHub Actions e o Azure Pipelines, a criação de um processo de implantação com anéis é acessível a equipes do DevOps de qualquer tamanho.

Sinalizadores de recurso

Às vezes, é necessário implantar determinadas funcionalidades como parte de uma versão, mas não expô-las inicialmente aos usuários. Nesses casos, os sinalizadores de recursos fornecem uma solução em que é possível ativar a funcionalidade via alterações de configuração com base no ambiente, no anel ou em qualquer outra implantação específica.

Aceitação do usuário

Semelhante a sinalizadores de recursos, a aceitação do usuário possibilita limitar a exposição. Nesse modelo, um recurso em especial é 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 possam decidir o quão rápido desejam adotar certas atualizações.

Múltiplas práticas costumam ser empregadas ao mesmo tempo. Por exemplo, uma equipe pode ter um recurso experimental destinado a um caso de uso bem específico. Como é arriscado, eles o implantarão no primeiro anel para os usuários internos testarem. Contudo, mesmo que os recursos estejam no código, alguém precisará definir o sinalizador de recurso para uma implantação específica no anel para a exposição do recurso via interface do usuário. Mesmo assim, o sinalizador de recurso pode expor somente a opção de um usuário para optar por usar o novo recurso. Qualquer pessoa que não esteja no anel, nessa implantação, ou não tenha optado por participar, não será exposta ao recurso. Apesar de fictício, este exemplo serve para ilustrar a flexibilidade e a praticidade da exposição progressiva.

Problemas comuns enfrentados por equipes logo no início

À medida que as equipes decidem adotar uma prática do Agile DevOps, elas podem se deparar com problemas parecidos com outras que migraram de entregas monolíticas tradicionais. As equipes acostumadas a fazer uma implantação com intervalo de alguns meses têm uma mentalidade voltada para a estabilização. Elas esperam que cada implantação traga uma mudança significativa no serviço e que haja problemas imprevistos.

Os conteúdos são grandes demais

Os serviços implantados com intervalo de alguns meses costumam ser preenchidos com muitas alterações. Isso aumenta a probabilidade de problemas imediatos e também torna difícil solucionar esses problemas pois existem muitas novidades. Ao migrar para entregas mais frequentes, diminuem as diferenças no que é implantado, permitindo testes mais focados e depuração mais fácil.

Nenhum isolamento de serviço

Os sistemas monolíticos costumam ser escalados nivelando o hardware em que são implantados. Mas, quando algo dá errado na instância, isso causa problemas para todos. Uma solução simples é adicionar várias instâncias para permitir balancear a carga de usuários. No entanto, isso pode exigir considerações arquitetônicas significativas, pois muitos sistemas herdados não são criados visando várias instâncias. Somado a isso, talvez seja necessário alocar recursos duplicados significativos para funcionalidades que possam ser melhor consolidadas em outros locais.

Com a adição de novos recursos, explore se uma arquitetura de microsserviços pode ajudá-lo a operar e escalar com um isolamento de serviço aprimorado.

Etapas manuais conduzem a erros

Quando uma equipe só implantar poucas vezes ao ano, talvez não valha a pena automatizar as entregas. Como resultado, muitos processos de implantação são gerenciados de forma manual. Isso exige muito tempo e esforço, e está sujeito a erros humanos. Basta automatizar as tarefas de compilação e implantação mais comuns para ajudar a reduzir muito o tempo perdido e erros não forçados.

As equipes também podem usar a infraestrutura como código para controlar melhor 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 apresentados 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 possam ter existido bons motivos para isso no passado, um processo do Agile DevOps se beneficia muito quando a equipe de desenvolvimento pode iniciar e controlar implantações. As plataformas modernas de entrega contínua oferecem controle granular de quem pode iniciar quais implantações e de quem pode acessar logs de status e outras informações de diagnóstico, garantindo que as pessoas certas tenham as informações certas o quanto antes.

Implantações incorretas prosseguem 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, existem várias ferramentas e práticas para mitigar o risco de implantações com falha.

Princípios básicos

As equipes que desejam adotar práticas de implantação segura devem definir alguns princípios básicos para sustentar o esforço.

Seja consistente

Use as mesmas ferramentas que utilizou para implantar na produção em ambientes de desenvolvimento e teste. Em caso de problemas, como os que costumam surgir de novas versões de dependências ou ferramentas, procure detectá-los bem antes da liberação do código para produção.

Fique atento aos sinais de qualidade

Um número excessivo de equipes caem na armadilha comum de não ficarem atentas a sinais de qualidade. Com o tempo, elas podem descobrir que escrevem testes ou assumem tarefas de qualidade simplesmente para mudar uma advertência amarela para uma aprovação verde. Os sinais de qualidade são de fato importantes, pois representam a pulsação de um projeto. Os sinais de qualidade usados para aprovar implantações devem ser rastreados constantemente todos os dias.

As implantações devem exigir zero tempo de inatividade

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

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

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

Implantação baseada em anéis

As equipes com práticas avançadas de lançamento do DevOps estão prontas para assumir a implantação baseada em anel. Nesse modelo, novos recursos são lançados primeiro para clientes dispostos a aceitar o risco maior. Conforme a implantação é comprovada, o público passa a incluir mais usuários até que todos a utilizem.

Um exemplo de modelo de anel

Um modelo típico de implantação em anel é criado para encontrar problemas o quanto antes por meio da segmentação cuidadosa de usuários e infraestrutura. O exemplo a seguir mostra como os anéis são usados por uma equipe importante da Microsoft.

Anel	Finalidade	Usuários	Data Center
0	Localiza a maioria dos bugs que afetam o usuário apresentados pela implantação	Apenas interno, alta tolerância a riscos e bugs	Centro-Oeste dos EUA
1	Áreas que a equipe não testa tanto	Clientes que utilizam uma variedade do produto	Um pequeno data center
2	Questões relativas à escala	Contas públicas, preferencialmente gratuitas usando um conjunto diversificado de recursos	Um data center de médio ou grande porte
3	Problemas de escala em contas internas e problemas internacionais	Grandes contas internas e clientes europeus	Data center interno e um data center europeu
4	Unidades de escala restantes	Todos os outros	Todos os destinos de implantação

Permitir tempo de preparação

O termo tempo de preparação refere-se à quantidade de tempo permitido para a execução de uma implantação antes de expandir para o próximo anel. Alguns problemas começam a apresentar sintomas após algumas horas ou mais tempo; portanto, a versão deve estar em uso por um período apropriado antes de ser considerada pronta.

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

Agilizar hotfixes

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

Se um bug for Sev 0, o tipo mais grave de bug, será possível implantar o hotfix direto na unidade de escala afetada o quanto antes, com responsabilidade. Embora seja essencial que a correção não piore as coisas, bugs dessa gravidade causam tanto transtorno que devem ser resolvidos logo.

Os bugs classificados como Sev 1 devem ser implantados através do anel 0, mas é possível implantá-los nas unidades de escala afetadas quando aprovados.

Os hotfixes para bugs com menor gravidade devem ser implantados em todos os anéis, conforme planejado.

Principais aspectos a serem lembrados

Toda equipe deseja oferecer rapidamente atualizações e com o nível de qualidade mais alto possível. Com as práticas certas, a entrega pode ser uma parte produtiva e simples do ciclo do DevOps.

• Procure implantar com frequência.
• Permaneça verde no sprint inteiro.
• Use ferramentas de implantação consistentes no desenvolvimento, no teste e na produção.
• Use uma plataforma de entrega contínua que permita automação e autorização.
• Adote práticas de implantação seguras.

Próximas etapas

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