Treinamento escrito de DevOps

Por que estabelecer um processo de revisão contínua para garantir a qualidade?

Muitas organizações dependem de revisões, auditorias, inspeções e aprovações pouco antes das implantações em produção. Geralmente, essas inspeções são conduzidas por pessoas com pouco ou nenhum envolvimento no trabalho. Pior ainda, às vezes os responsáveis pela inspeção e aprovação entendem o trabalho de maneira incorreta, e você precisa explicá-lo às vésperas da implantação.

Problemas dos mecanismos de controle externo

Na maioria das organizações, criar controles é mais fácil que criar confiança mútua. Assim, é comum que os mecanismos externos acrescentem perguntas aos formulários de controle de mudanças, criem novas camadas hierárquicas de aprovação e exijam mais tempo para compreender e aprovar cada mudança.

Ambientes com pouca confiança e cultura de comando e controle sofrem com incidentes que se repetem. Cria-se um ciclo vicioso porque falta transparência sobre o trabalho realizado e sobre os problemas recorrentes. As equipes também acumulam trabalho em lotes grandes para reduzir a frequência de implantações problemáticas. Prazos de entrega mais longos prejudicam a capacidade de chegar ao mercado rapidamente. Feedback lento, tardio e difícil de transformar em ação impede que as equipes aprendam com os erros.

Uma organização DevOps competente sabe que quem está mais perto do trabalho conhece melhor sua execução e os problemas associados. Mecanismos externos de controle e aprovação, portanto, não agregam valor ao fluxo. Isso nos leva a um dos maiores desafios de gestão e liderança do nosso tempo: construir culturas de confiança, em que o trabalho seja transparente e o respeito genuíno e a confiança mútua façam parte do dia a dia.

Reduza a dependência de inspeções periódicas e incorpore a revisão por pares ao trabalho diário. Faça com que desenvolvedores, engenheiros de operações, especialistas em garantia da qualidade e especialistas em segurança da informação colaborem e revisem continuamente o trabalho uns dos outros para viabilizar implantações seguras.

Coordenação de trabalhos complexos sem mecanismos de controle externo

O trabalho já é complexo quando uma única equipe conduz o projeto, mas pode ficar ainda mais complexo quando várias equipes trabalham em componentes diferentes do mesmo sistema. Algumas medidas para lidar com isso são:

• Comitês de mudanças formados por especialistas, além de gerentes, podem ajudar a identificar dependências entre equipes antes que as mudanças ocorram.
• Arquiteturas com baixo acoplamento baseadas em SOA e microsserviços reduzem as dependências e o esforço de comunicação.
• Os representantes técnicos das equipes DevOps devem identificar as dependências e a sequência de desenvolvimento e implantação.
• Mantenha a comunicação contínua em plataformas de bate-papo compartilhadas para sincronizar mudanças e verificar o entendimento dos demais.
• Mudanças mais arriscadas e de maior impacto, como migrações ou alterações na infraestrutura, exigem ensaios em ambientes de teste e medidas técnicas de contingência, como mecanismos de failover e de reversão completa.

Organizações DevOps de alto desempenho se apoiam mais na revisão por pares e menos nas aprovações externas

Muitas organizações DevOps de destaque, como Amazon, Netflix, Etsy e GitHub, usam o processo de revisão e implantação por “Pull Request”. Funciona assim:

1. A desenvolvedora cria uma ramificação de desenvolvimento a partir do trunk. A ramificação deve durar no máximo alguns dias úteis e ter um nome claro e descritivo, como “login-screen-v2”. Ela trabalha na ramificação localmente e envia as mudanças regularmente ao sistema de controle de versão.
2. Quando considera que a ramificação está pronta para ser mesclada ao trunk, a desenvolvedora abre um “pull request” para solicitar feedback na revisão.
3. Depois de receber comentários e aprovação de colegas da equipe DevOps, ela mescla seu código ao trunk. Em seguida, implanta o código nos sistemas de produção.

Para mudanças de maior impacto, como alterações em esquemas de bancos de dados ou na segurança da informação das aplicações, a desenvolvedora também pode enviar “pull requests” adicionais para obter feedback de outros especialistas na organização, como administradores de bancos de dados ou especialistas em segurança da informação.

Aplique também o princípio dos lotes pequenos na revisão de código. Caso contrário, a revisão demora mais e sobrecarrega quem revisa. Quanto maior a mudança, mais o risco cresce exponencialmente e menos confiável fica a revisão. Se uma mudança for grande demais e difícil de entender, peça à desenvolvedora que a divida em partes menores e mais fáceis de compreender.

Todos os integrantes da equipe DevOps, independentemente da senioridade e da experiência, devem ter suas mudanças revisadas por outra pessoa. Todos devem acompanhar o fluxo de commits para identificar e resolver conflitos rapidamente, antes que causem problemas maiores no pipeline ou, pior, durante implantações em produção.

A programação em pares, sozinha ou combinada com o desenvolvimento orientado a testes (TDD), permite que a equipe faça revisão por pares enquanto o código é escrito. Na abordagem combinada, um desenvolvedor escreve o código da aplicação e o outro escreve o teste automatizado. Com equipes do mesmo tamanho e os mesmos requisitos de projeto, medições comprovaram que a programação em pares exige 15% mais tempo, mas reduz os erros de programação em 85%. Por isso, é uma prática que vale a pena avaliar.

Considere também revisões feitas lado a lado, notificações automáticas dos envios de código e ferramentas que ajudem a revisar e melhorar a qualidade do código.

CONCLUSÃO

Faça com que cada equipe DevOps seja responsável pela qualidade de suas entregas. Crie uma cultura que valorize revisões contínuas e cuidadosas tanto quanto a escrita de código de qualidade.