Seis armadilhas do DevOps que devem ser evitadas pelos líderes da engenharia

1. Transformação parcial da organização

É possível implementar o DevOps em sua organização de software e, ainda assim, não ver melhorias gerais na velocidade da entrega. Em muitos casos, isso ocorre devido à implementação dos princípios do DevOps apenas no departamento de engenharia, enquanto todos os outros setores não passam por qualquer tipo de transformação no organograma da sua empresa. Como o DevOps é um modelo de entrega de software mais ágil, equipes fora do desenvolvimento de software também precisam se alinhar para corresponder à mudança, incluindo TI, UX, produtos e marketing.

2. Automação de testes incompleta

Entrega contínua também significa teste contínuo. Configurar a automação de testes pode ser um processo intenso e demorado, o que significa que algumas equipes preferem executar certos testes complexos manualmente. Ao optar por esse caminho, não é possível executar o conjunto completo de testes a cada confirmação. Na melhor das hipóteses, você só poderá executar um conjunto essencial de testes após a confirmação, deixando o conjunto completo de testes para ser executado periodicamente. Essa prática pode dificultar a identificação de bugs no decorrer do fluxo de trabalho, dificultando cada vez mais a correção.

3. Problemas de integração de ferramentas

O seu conjunto de ferramentas de DevOps contém aplicações para controle de código-fonte, CI (integração contínua), implantação, teste, provisionamento de infraestrutura e até mesmo notificações. Qual é a probabilidade de todos esses itens se comunicarem entre si? Muitas organizações de software acabam gerenciando a toolchain de DevOps manualmente ou usando scripts personalizados para conectar tudo, o que é uma abordagem que fica menos sustentável à medida que mais ferramentas e casos são adicionados. Para resolver esse problema, o GitHub lançou recentemente uma nova funcionalidade chamada GitHub Actions, que permite que etapas de fluxo de trabalho sejam tratadas como código, unindo as integrações conforme necessário.

4. Volume e velocidade em excesso

Uma boa razão pela qual muitas empresas adotam um modelo DevOps é que suas equipes de desenvolvimento estão sobrecarregadas. Contudo, uma carga de trabalho excessiva também pode fazer com que a implementação do DevOps falhe. Apresentar novas ferramentas e processos a uma equipe que já está se esforçando para gerenciar a carga de trabalho atual é a fórmula para o caos, o esgotamento dos funcionários e uma maior rotatividade. Antes de tentar fazer uma transição para o DevOps, reveja as prioridades e adie ou delegue o trabalho para prestadores de serviço sempre que possível.

5. Medo de falhar

O DevOps cria um ambiente mais tolerante a falhas, mas isso não significa que seja livre de falhas. Depois de precisar lidar com uma falha, muitas organizações iniciantes em DevOps cometem o erro de culpar determinado ponto no fluxo de trabalho. Em vez disso, trate a falha como uma oportunidade de aprendizado. Lidar com o problema de forma resoluta e sem abrir margem para ainda mais estresse é muito mais útil. Algumas empresas, como a Netflix, de fato provocam falhas simuladas de propósito para que suas equipes se acostumem a lidar com elas.

6. Anarquia total de produtos

A flexibilidade do DevOps pode ser tanto uma vantagem quanto um fardo. Intencionalmente, ele proporciona às equipes de DevOps mais poder e autonomia, mas essas equipes também podem acabar fazendo coisas que não deveriam. Em ambientes mais caóticos, recursos e reformulações que não foram bem avaliados podem ser implantados, emendados ou até mesmo revertidos, causando frustração nos clientes. Antes de implementar o DevOps, vale a pena projetar com cautela algumas aprovações e controles em seus processos.