Home  >  Sem Categoria

3 fatores essenciais para escalar a cultura de DevOps na empresa

Insights foram coletados na edição 2020 do relatório 'State of DevOps', divulgado pela Puppet e CircleCI; confira os fatores apontados como essenciais

Scott Carey, da Infoworld

27/11/2020 às 11h00

Foto: Adodbe Stock

As organizações mais maduras em suas jornadas de DevOps contam com plataformas internas de autoatendimento, processos automatizados de gerenciamento de mudanças e segurança integrada, de acordo com o relatório 2020 State of Devops da Puppet e CircleCI.

A pesquisa entrevistou mais de 2,4 mil profissionais técnicos em todo o mundo sobre sua adoção contínua de DevOps e práticas ágeis, com três temas principais emergindo das organizações mais maduras e de alto desempenho: alavancagem de plataformas internas, estabelecimento de processos eficazes de gerenciamento de mudança e integração total de segurança. Vamos encará-los um por um.

1. Desenvolvimento de plataformas internas

As plataformas internas surgem quando as organizações têm equipes fortes e focadas no produto, cada uma responsável pela entrega ponta a ponta de um produto ou serviço.

Essa plataforma interna tende a ser um local centralizado para o fornecimento de autoatendimento de infraestrutura, ambientes de teste, pipelines de implantação, APIs, ferramentas, conhecimento, governança e suporte. A equipe responsável por essa plataforma interna normalmente reunirá os requisitos de negócios, fornecerá um roteiro do produto e ajudará a integrar novos usuários.

A plataforma interna permite que as equipes de desenvolvimento de aplicativos criem, implantem e executem seus aplicativos de maneira padronizada e difere das plataformas como serviço genéricas vendidas por fornecedores como AWS, Azure, Google Cloud Platform, IBM/Red Hat ou VMware.

Como acontece com qualquer grande ideia, essa iniciativa pode dar com a cara na parede quando aplicada em uma empresa altamente complexa, com centenas de produtos ou serviços e com várias equipes atendendo a cada um com seus próprios processos e tarefas.

“Um dos motivos pelos quais o DevOps muitas vezes não consegue se expandir ainda é que a maioria das empresas está estruturada de maneiras que criam incentivos desalinhados e falta de responsabilidade ou propriedade sobre os resultados que deveriam estar gerando”, escrevem os autores do relatório.

2. Desafios de desenvolvimento empresarial na implementação do DevOps

Essa falta de padronização leva a um conjunto comum de desafios de desenvolvimento empresarial. O relatório identifica três:

  • A governança se torna cara e quase impossível de gerenciar;
  • Sprints e projetos separados reduzem o compartilhamento de conhecimento em toda a organização;
  • Muitas das equipes de produto não têm realmente as habilidades ou conhecimentos para operar uma base completa de infraestrutura e aplicativos.

As organizações que são capazes de construir uma plataforma, com a experiência do desenvolvedor em mente, podem começar a padronizar as práticas de desenvolvimento e reduzir o trabalho pesado e as despesas gerais.

Essa plataforma deve permitir provisionamento, configuração e gerenciamento de autoatendimento, de forma que cada equipe possa se concentrar em seu produto sem ter que esperar que uma equipe centralizada forneça a infraestrutura para eles.

“Concentre-se na experiência e no fluxo do desenvolvedor. Não podemos enfatizar o suficiente que a empatia é um conjunto de habilidades críticas. Empatia significa entender a posição de alguém, e é impossível construir um bom produto sem ter empatia por seu usuário”, avisa o relatório.

A construção de uma plataforma interna é uma abordagem cada vez mais popular entre os entrevistados da pesquisa State of DevOps, com 63% afirmando ter pelo menos uma plataforma interna de autoatendimento. Daqueles que tinham plataformas internas, 60% tinham entre duas e quatro, e quase um terço daqueles com plataformas internas tinham 26% a 50% de seus desenvolvedores usando pelo menos uma plataforma interna.

O motivo da proliferação de plataformas é que os profissionais de DevOps mais bem-sucedidos começam de forma discreta, desenvolvendo plataformas para uma equipe específica ou para um determinado tipo de infraestrutura - como nuvem pública - e aumentando a partir daí.

Essa abordagem é melhor do que tentar construir uma plataforma para governar a todos com base em um conjunto de suposições gerais sobre o que suas equipes precisam. Uma abordagem “construa e eles virão”, neste caso, está fadada ao fracasso.

Mais importante: as empresas mais evoluídas, conforme definido pelos autores do relatório, tinham quase duas vezes mais probabilidade do que as organizações de nível médio de relatar alto uso de plataformas internas e seis vezes mais probabilidade de relatar alto uso do que as organizações de baixo nível.

3. Padronização do gerenciamento de mudanças

Para as organizações que ainda estão trabalhando em direção a uma plataforma interna, o gerenciamento de mudanças eficaz é o melhor caminho.

A mudança macro de projetos em cascata e grandes lançamentos de software para microsserviços e ciclos de implantação mais rápidos e regulares permitiu que os DevOps florescessem e exige que as equipes adotem totalmente as mudanças constantes.

Tornar esse processo de gerenciamento de mudanças consistente é uma das partes mais difíceis de devops em escala empresarial. É também um diferencial importante para quem deseja lançar mais software com mais frequência.

Os participantes da pesquisa citaram a cobertura de teste incompleta como a maior barreira para o gerenciamento de mudanças eficaz, seguida por mentalidades organizacionais estabelecidas e arquiteturas de aplicativos fortemente acopladas.

Somente quebrando silos entre gerenciamento de mudanças, gerenciamento de liberação e equipes de auditoria e conformidade, criando ciclos eficazes de feedback e controlando o progresso, as organizações são capazes de amadurecer seus processos de gestão de mudanças.

O sucesso do gerenciamento de mudanças pode ser medido rastreando as principais métricas, como taxa de falha de mudança e frequência de implantação, o nível de eficiência em torno das aprovações e o nível de risco aceitável para os negócios.

De acordo com o relatório, os processos mais eficazes de gestão de mudança surgem quando as equipes empregam:

  • Um alto grau de automação de teste e implantação;
  • Alto grau de mitigação de risco automatizada;
  • Menor rigidez e processos bem reduzidos de aprovação manual;
  • Registros por escrito de alterações no código;
  • Habilitam os funcionários a ter mais espaço para influenciar a gestão da mudança;
  • Processos e cultura alinhados ao DevOps.

Em suma, o aumento da automação gera confiança no gerenciamento de mudanças. O relatório descobriu que as empresas com aprovações altamente ortodoxas têm nove vezes mais probabilidade de ver altos níveis de ineficiência em seu processo de gerenciamento de mudanças do que aquelas com baixos níveis de aprovações ortodoxas.

O espectro do gerenciamento de mudança automatizado começa com a revisão secundária, ou seja, sem automação, até o santo graal da implantação e teste totalmente automatizados, com avaliação de risco integrada e recursos de progressão imediata.

Foco na integração de segurança

Por último, o relatório enfocou a integração da segurança. “Descobrimos que as empresas que alcançaram níveis mais altos de integração de segurança têm muito mais probabilidade de estar em um estágio alto de evolução de DevOps”, concluiu o relatório.

Por integração de segurança, o relatório pede especificamente “uma abordagem completamente diferente, que enfatiza a colaboração entre equipes e capacita equipes de entrega para prevenir, descobrir e corrigir problemas de segurança de forma autônoma. Romper os silos de conhecimento entre as equipes e colaborar para melhorar a segurança aumentam a consciência geral das questões de segurança, tornando mais provável que todos - mesmo aqueles fora da equipe de segurança - adotem padrões conhecidos para proteção de segurança”.

O relatório mostrou uma forte correlação entre a capacidade de integrar a segurança totalmente ao processo de entrega de software e a capacidade de uma organização de remediar vulnerabilidades críticas rapidamente.

Especificamente, 45% das empresas com integração total de segurança relataram ser capazes de remediar vulnerabilidades críticas em um dia, enquanto apenas 25% das empresas com integração de segurança baixa poderiam fazer o mesmo.

Tags