DevOps: rompendo a barreira entre desenvolvimento e operações

Ilustração do ciclo de DevOps

O que é DevOps?

O DevOps é um conjunto de práticas que automatizam e integram os processos entre equipes de desenvolvimento de software e de TI para que possam criar, testar e lançar software com mais velocidade e confiabilidade. O termo DevOps foi formado pela combinação das palavras "desenvolvimento" e "operações" e indica uma mudança cultural que preenche a lacuna entre equipes de desenvolvimento e operação, que têm um histórico de funcionar em silos. 

Símbolo do infinito do DevOps da Atlassian

Em essência, DevOps é uma cultura, um movimento, uma filosofia.

É um aperto de mão firme entre desenvolvimento e operações que enfatiza uma mudança de mentalidade, melhor colaboração e integração mais estreita. Ele une agilidade, Git, entrega contínua, automação e muito mais para ajudar as equipes de desenvolvimento e operações a serem mais eficientes, inovarem mais rápido e gerarem mais valor aos negócios e aos clientes.


O DevOps não é o trabalho de uma pessoa individual. É o trabalho de todos.

Christophe Capel
Gerente principal de produto, Jira Service Desk

Logotipo Chef.io

Quem está realizando DevOps?

Chef é a empresa por trás da plataforma Chef Automate para fluxos de trabalho de DevOps. Dezenas de milhares de desenvolvedores usam Chef para testar, automatizar e gerenciar a infraestrutura. Na vanguarda da evolução de DevOps, a empresa baseada em Seattle lançou produtos como Chef, InSpec, Habitat e Chef Automate para aprimorar novas maneiras de desenvolver e enviar software e aplicativos. Para experimentar e refinar suas próprias práticas de DevOps, a Chef conta com a plataforma da Atlassian.

História do DevOps

O movimento do DevOps começou a tomar forma em algum momento entre 2007 e 2008, quando as operações de TI e as comunidades de desenvolvimento de software passaram a expressar o que acreditavam ser um nível fatal de disfuncionalidade no setor.

Elas foram contra o modelo tradicional de desenvolvimento de software, que exigia que quem escrevia o código estivesse separado em termos organizacionais e funcionais de quem implementava e dava suporte ao código.

Desenvolvedores e profissionais de TI/Ops tinham objetivos separados (e às vezes concorrentes), liderança de departamento separada, eram avaliados por indicadores-chave de desempenho separados e muitas vezes trabalhavam em andares ou mesmo prédios separados. Isso tinha como resultado em equipes em silos preocupadas apenas com o próprio escopo, horas mais longas de trabalho, versões problemáticas e clientes insatisfeitos. Elas tinham certeza de que deveria ter um jeito melhor. Assim, as duas comunidades se uniram e começaram a conversar, tendo pessoas como Patrick Dubois, Gene Kim e John Willis conduzindo a conversa.

O que começou em fóruns on-line e reuniões locais agora é um importante tema no zeitgeist do software, e provavelmente é o que o trouxe aqui! Você e sua equipe estão sentindo a dor causada por equipes em silos e linhas de comunicação divididas dentro da sua empresa.

Você está usando metodologias ágeis para planejamento e desenvolvimento, mas ainda tem dificuldade em liberar aquele código sem muito drama. Você já deve ter ouvido algumas coisas sobre DevOps e o efeito que isso pode ter nas equipes (parece até mágica): quase todas (99%) as equipes de DevOps têm confiança no sucesso do código que entra em produção, segundo uma pesquisa sobre 500 profissionais de DevOps conduzidos pela Atlassian¹.

Mas DevOps não é mágica, e as transformações não acontecem da noite para o dia. A boa notícia é que você não precisa esperar a alta gerência para implementar uma iniciativa em grande escala. Ao entender o valor de DevOps e fazer pequenas mudanças incrementais, sua equipe pode embarcar na jornada de DevOps na hora. Vamos analisar cada um desses benefícios em detalhes.

Comparados aos executivos da diretoria, os profissionais de DevOps “em campo” têm uma probabilidade maior de concordar que é difícil medir o impacto do progresso e sucesso de DevOps: 62% concordam em comparação com 46% dos executivos da diretoria.

Pesquisa da Atlassian com profissionais de DevOps

Benefícios

Ícone de pessoas conectadas

Colaboração e confiança

A gente realizou uma pesquisa que constatou que o fator número um de uma equipe de DevOps com bom desempenho é a colaboração. Criar uma cultura de responsabilidade compartilhada, transparência e feedback mais rápido é a base de toda equipe de DevOps de alto desempenho. A colaboração e a solução de problemas são os elementos classificados como os mais importantes de uma cultura bem-sucedida de DevOps, de acordo com nossa pesquisa. 

Equipes que trabalham em silos muitas vezes não aderem ao "pensamento de sistemas" do DevOps. O "pensamento de sistemas" é estar ciente de como suas ações não apenas afetam a sua equipe, mas todas as outras equipes envolvidas no processo de lançamento. A falta de visibilidade e de metas compartilhadas gera a falta de planejamento de dependência, prioridades desalinhadas, busca de culpados e a mentalidade "não é problema nosso", resultando em menor velocidade e qualidade abaixo do padrão. O DevOps é essa mudança de mentalidade ao analisar o processo de desenvolvimento de maneira holística e derrubar a barreira entre Desenvolvedores e Operações.

Ícone de velocímetro

Libere versões mais rapidamente e trabalhe de modo mais inteligente

Velocidade é tudo. Equipes que praticam DevOps lançam versões com mais frequência e com qualidade e estabilidade maiores.  

A falta de ciclos automatizados de teste e revisão atrasa o lançamento para produção, e o tempo de resposta a incidentes insatisfatório mina a velocidade e a confiança da equipe. Ferramentas e processos distintos aumentam os custos operacionais, levam à mudança de contexto e desaceleram o ritmo. No entanto, com ferramentas que impulsionam a automação e processos novos, as equipes podem aumentar a produtividade e lançar com mais frequência com menos contratempos.

Ícone de batida do coração

Acelere o tempo para a resolução

A equipe com o ciclo de feedback mais rápido é a que prospera. Transparência total e comunicação contínua possibilitam às equipes de DevOps minimizar o tempo de inatividade e resolver problemas mais rápido.

Se problemas críticos não forem resolvidos logo, a satisfação do cliente diminui. Problemas importantes entram pelas frestas na ausência de comunicação aberta, resultando em maior tensão e frustração entre as equipes. Comunicação aberta ajuda as equipes de Desenvolvimento e Operações a atacar problemas, corrigir incidentes e desbloquear o pipeline de lançamento mais rápido.

Ícone de ferramentas

Gerencie melhor o trabalho não planejado

Trabalho não planejado é uma realidade que todas as equipes enfrentam — uma realidade que costuma afetar a produtividade da equipe. Com processos estabelecidos e priorização clara, as equipes de Desenvolvimento e Operações podem gerenciar melhor o trabalho não planejado, enquanto continuam a focar no trabalho planejado.

Fazer a transição e priorizar o trabalho não planejado em diferentes equipes e sistemas é ineficiente e distrai do trabalho em questão. Porém, com maior visibilidade e retrospecção proativa, as equipes podem prever e compartilhar melhor o trabalho não planejado.

A estrutura CALMS para DevOps

CALMS é uma estrutura que avalia a capacidade de uma empresa adotar processos de DevOps, bem como uma maneira de medir o sucesso durante uma transformação de DevOps. O acrônimo foi criado por Jez Humble, coautor de "The DevOps Handbook", e representa:


Ícone de camiseta

Cultura

O DevOps não é só um processo ou uma abordagem diferente para o desenvolvimento: é uma mudança de cultura. E uma parte importante da cultura DevOps é a colaboração. 

Todas as ferramentas e automação do mundo são inúteis, a menos que os profissionais de desenvolvimento e TI/Ops trabalhem juntos. Porque DevOps não resolve problemas de ferramentas. Resolve problemas humanos. 

Pense em DevOps como uma evolução de equipes ágeis — a diferença é que agora as operações estão incluídas por padrão. Formar equipes orientadas por projeto ou produto para substituir equipes com base em funções é um passo na direção certa. Inclua desenvolvimento, garantia de qualidade, gerenciamento de produto, design, operações, gerenciamento de projeto e qualquer outro conjunto de habilidades que o projeto exija. Em vez de ter uma equipe fazendo tudo ou contratar "profissionais de DevOps", é mais importante ter equipes com base em projetos que possam trabalhar juntas sem problemas.  

Poucas coisas promovem mais a colaboração do que compartilhar um objetivo comum e um plano para chegar lá juntos. Em algumas empresas, mudar de repente para equipes com base em projetos é excessivo e precoce. Por isso, comece aos poucos. As equipes de desenvolvimento podem (e devem) convidar os membros adequados da equipe de operações para participar de sessões de planejamento, reuniões rápidas diárias e demonstrações de sprint. As equipes de operações podem convidar os principais desenvolvedores para suas reuniões. É uma maneira ágil e orgânica de acompanhar o andamento dos projetos, das ideias e das dificuldades uns dos outros. 

Desafios e até emergências são testes eficazes da cultura de DevOps. Os setores de desenvolvimento, operações e suporte ao cliente atacam o problema para resolver em equipe? A análise post-mortem do incidente é focada na correção dos processos em vez de em encontrar culpados? Se a resposta for "sim", isso é uma boa indicação de que sua equipe está trabalhando em uma estrutura de DevOps.

Observe que as empresas mais bem-sucedidas adotaram a cultura DevOps em todos os departamentos e em todos os níveis do fluxograma. Elas têm canais abertos de comunicação e conversam regularmente. Elas presumem que manter o cliente satisfeito é tanto responsabilidade do gerenciamento de produto quanto da equipe de desenvolvimento. Elas entendem que DevOps não é trabalho de apenas uma equipe. É o trabalho de todos.

Ilustração de engrenagens

Automação

Investir em automação elimina o trabalho manual repetitivo, produz processos repetíveis e cria sistemas confiáveis.

Compilação, teste, implementação e provisionamento automatizados são o ponto de partida típico para equipes que ainda não têm isso implantado. E, veja só: quer motivo melhor para desenvolvedores, testadores e operadores trabalharem juntos que criar sistemas para o benefício de todos?

Equipes novas em automação em geral começam com entrega contínua: a prática de executar cada mudança de código ao longo de uma odisseia de testes automatizados — muitas vezes facilitados por infraestrutura baseada em nuvem — depois o empacotamento de builds e sua promoção para produção usando implementações automatizadas. 

Por quê? Computadores executam testes com mais rigor e fidelidade que humanos. Esses testes detectam bugs e falhas de segurança mais cedo. E as implementações automatizadas alertam a TI/Ops sobre "desvios" de servidor entre ambientes, o que reduz ou elimina surpresas na hora do lançamento.

Outra grande contribuição do DevOps é "configuração como código". Os desenvolvedores trabalham para criar aplicativos modulares e que possam ser combinados, porque eles são mais confiáveis e sua manutenção é mais fácil. O mesmo pensamento pode ser expandido para a infraestrutura que os hospeda, estejam eles na nuvem ou na rede da própria empresa.

"Configuração como código" e "entrega contínua" não são os únicos tipos de automação no mundo do DevOps, mas merecem menção especial porque ajudam a derrubar a barreira entre desenvolvimento e operações. E, quando o DevOps usa implementações automatizadas para enviar códigos testados com todo o cuidado para ambientes com provisionamento idêntico, "Funciona no meu computador!" vira irrelevante.

Ícone Lean DevOps

Enxuto

Quando se escuta "enxuto" no contexto de software, é normal pensar em eliminar atividades de baixo valor e avançar rápido — sendo fragmentário e ágil. Ainda mais relevantes para o DevOps são os conceitos de melhoria contínua e aceitação de falhas — que lançam as bases de uma mentalidade experimental.

Uma mentalidade de DevOps vê oportunidades de melhoria contínua em toda parte. Algumas são óbvias, como realizar retrospectivas regulares para que os processos da sua equipe possam melhorar. Outras são sutis, como teste A/B de diferentes abordagens de integração para novos usuários do seu produto.

Podemos agradecer o desenvolvimento agile por tornar a melhoria contínua em uma ideia dominante. Os primeiros a adotar a metodologia agile comprovaram que um produto simples nas mãos dos clientes hoje vale mais que um produto perfeito nas mãos dos clientes daqui a seis meses. Se o produto for melhorado continuamente, os clientes se manterão fiéis.

Adivinhe só: falhar é inevitável. Então você pode muito bem preparar sua equipe para absorver isso, recuperar-se e aprender com as falhas (alguns chamam isso de "ser antifrágil"). Na Atlassian, acreditamos que, se você não falha de vez em quando, não está se esforçando o bastante.

No contexto do DevOps, falhar não é um crime condenável. As equipes presumem que tudo está fadado a desandar em algum momento, assim, elas criam pensando em detecção e recuperação rápidas. Análises post-mortem focam no ponto em que o processo desandou e como torná-lo mais consistente, não em qual membro da equipe inseriu o código. Por quê? Porque melhoria contínua e falha andam lado a lado.

Ilustração da régua

Medição

É difícil provar que nossos esforços de melhoria contínua estão de fato rendendo qualquer melhoria sem dados. Ainda bem que há muitas ferramentas e tecnologias para medir o desempenho, como o tempo que os usuários dedicam ao seu produto, se uma postagem de blog gerou alguma venda ou com que frequência alertas críticos aparecem nos seus logs.

Embora você possa medir praticamente qualquer coisa, isso não significa que precise (ou deva) medir tudo. Pegue uma página do desenvolvimento agile e comece com o básico:

  • Quanto tempo levou para ir do desenvolvimento à implementação? 
  • Com que frequência erros ou falhas recorrentes acontecem?
  • Quanto tempo a recuperação leva depois de uma falha do sistema?
  • Quantas pessoas estão usando seu produto no momento?
  • Quantos usuários você ganhou/perdeu nesta semana?

Com uma base forte estabelecida, é mais fácil capturar métricas mais sofisticadas quanto ao uso de recursos, jornadas do cliente e acordos de nível de serviço (SLAs). As informações que você obtém vêm a calhar quando é hora de mapear o roteiro e especificar sua próxima ação importante.

Todos esses dados interessantes vão ajudar a sua equipe a tomar decisões, mas são ainda mais eficientes quando compartilhados com outras equipes (ainda mais se forem de outros departamentos). Por exemplo, as equipes de marketing querem recursos novos e atraentes que possam vender. Porém, enquanto isso, você está percebendo uma alta rotatividade de clientes porque o produto está cheio de débitos técnicos. Usar dados dos usuários como base para o roteiro (mesmo que tenha poucos recursos e muitas correções) torna mais fácil obter um consenso e adesão das partes interessadas.

Ilustração de bolhas de mensagens

Compartilhamento

O antigo conflito entre equipes de desenvolvimento e operações tem muito a ver com a falta de uma base comum. A gente acredita que compartilhar responsabilidades e sucessos ajuda muito a criar uma ponte entre elas. Os desenvolvedores vão ter boa-vontade instantânea ao ajudar a realizar uma das cargas mais pesadas da equipe de operações: o paginador. O DevOps é ambicioso na ideia de que as mesmas pessoas que criam um aplicativo devem estar envolvidas no lançamento e na execução.

Isso não significa que você contrata desenvolvedores e simplesmente espera que eles sejam excelentes operadores também. Significa que desenvolvedores e operadores trabalham juntos em cada fase do ciclo de vida do aplicativo.

As equipes que adotam o DevOps costumam ter uma função rotativa na qual os desenvolvedores resolvem problemas detectados pelos usuários finais e, ao mesmo tempo, resolvem problemas de produção. Essa pessoa responde a problemas urgentes relatados pelo cliente, criando correções quando necessário, e trabalha com o backlog de defeitos relatados pelo cliente. O "desenvolvedor no suporte" aprende muito sobre como o aplicativo é usado no mundo real. Com a alta disponibilidade à equipe de operações, as equipes de desenvolvimento estabelecem confiança e respeito mútuo.

Seria ótimo se tivesse uma varinha mágica para transformar todas as equipes em equipes de alto desempenho de DevOps, mas as transformações de DevOps exigem uma mistura de práticas, filosofias culturais e ferramentas. Mesmo assim, como você leu, os benefícios de quebrar os silos de Desenvolvimento e Operações valem a pena — maior confiança, lançamentos de software mais rápidos, implementações mais confiáveis e um melhor ciclo de feedback entre equipes e clientes.

Implementar o DevOps não é uma tarefa pequena. No entanto, com a estrutura, o esforço e as ferramentas corretas, uma empresa pode passar por uma transformação de DevOps que produz benefícios significativos. 

Entre em contato pelo press@atlassian.com para saber mais sobre a pesquisa, realizada em parceria com a Cite Research.

Pronto para começar sua jornada de DevOps?