Antes de falar sobre o que é DevOps, me permita dizer o que não é DevOps para acabar logo com a minha ansiedade. É que sempre que surge uma nova BuzzWord, imediatamente toda uma indústria emerge ao redor dela, com produtos, selos, treinamentos e certificações. Isso, por si só, não é o problema, mas apenas uma manifestação natural do capitalismo. O problema é quando a mensagem começa a chegar na fase de maioria inicial (Early Majority), segundo a teoria da difusão de inovação de Rogers (1962), o conceito já se misturou tanto com a sua “produtização” que as pessoas já não sabem mais o que é conceito ou o que é produto.
DevOps não é um produto, ferramenta ou carreira. Portanto, se alguma empresa lhe ofertar produtos de DevOps, por favor, questione sua credibilidade. DevOps não se compra, não se instala, tão pouco se configura.
DevOps é um movimento cultural. Inspirado pelo Manifesto Ágil (2001), a ideologia que o embala remete à histórica divergência cultural que existe entre os times de desenvolvimento e operação.
O termo teve origem durante uma conferência, em 2009, na Bélgica, chamada de “DevOpsDays”, organizada por Patrick Debois, que reuniu em um mesmo evento times de desenvolvimento e infraestrutura com objetivo de que ambos percebessem que esse problema histórico é prejudicial, equivocado e superável e que existem formas de se trabalhar juntos e serem mais felizes!
O que este movimento se propõe a resolver
O status quo da indústria de software hoje é que os projetos vão atrasar, quando entregues (se entregues!), não vão se comportar bem no ambiente de produção, que apresentarão problemas de performance e não corresponderão às expectativas dos patrocinadores.
Nesse primeiro artigo sobre DevOps, vamos falar sobre os problemas comuns que enfrentamos hoje na entrega de projetos de TI.
Medo de mudança
Uma vez que uma versão de software finalmente é entregue, os stakeholders tendem a ter um medo tremendo de mudança, pois acreditam que software e ambientes são coisas frágeis e vulneráveis, que qualquer mínima interferência é suficiente para quebrar a aplicação e tirá-la do ar. É instaurado, então, um processo caro e burocrático de gestão de mudanças e então um longo e doloroso caminho tem que ser percorrido para que seja possível atualizar versões das aplicações ou mesmo corrigir erros.
Deployments arriscados
Na maioria das vezes, desenvolvedores não sabem como seus códigos irão se comportar no ambiente de produção. Será que vai tudo funcionar como esperado? Será que vai suportar o volume de acesso? Normalmente, desenvolvedores não têm respostas para essas perguntas. Eles apenas colocam uma nova versão no ambiente de produção e observam para ver se ele vai continuar de pé.
Funciona na minha máquina
Uma situação bastante comum são problemas que se manifestam apenas no ambiente de produção. Estes problemas normalmente são identificados pelo time de Infra ou Help Desk, quando os próprios usuários descobrem e reportam os problemas. Após investigação, os problemas são reportados para os desenvolvedores, que depois de uma olhada rápida soltam a célebre frase “na minha máquina funciona”.
Entretanto, funcionar na máquina do desenvolvedor frequentemente não significa nada. Não é raro ver desenvolvedores codificando aplicações Java em computadores com Windows XP, realizando os testes no Tomcat rodando no Windows, então publicando a aplicação em um Linux RedHat, com balanceadores de carga, em diferentes versões do Java e diferentes versões do Tomcat. Isso para não dizer sobre os arquivos de configuração nas máquinas dos desenvolvedores comparados com as máquinas de produção.
Silos
Na maioria das empresas, os times são divididos entre desenvolvedores, testadores, gestores de configuração e o pessoal da Infra, todos trabalhando em diferentes silos. Sob a perspectiva de processo, isso é um tremendo desperdício. Isso também pode levar a uma filosofia de “passar a batata quente”, onde os problemas são transferidos entre os analistas de negócios, desenvolvedores, especialistas de qualidade e infra.
É comum que estes silos não estejam localizados fisicamente dentro do mesmo escritório, na mesma cidade ou ainda no mesmo país. O resultado disso é que se cria uma mentalidade do tipo “Nós e Eles” onde os times suspeitam e têm receio uns dos outros.
Foco e Visão
Existe claramente um déficit de visão compartilhada entre os responsáveis por construir e operar aplicações. Enquanto desenvolvedores endeusam seus códigos, muitas vezes sem perceber que se tratam de códigos “mal cheirosos” com alta complexidade ciclomática, alto acoplamento e baixa coesão, analistas de infraestrutura se encastelam em suas fortalezas, cuidando de seus ambientes e combatendo tudo e todos que podem de alguma forma colocar em xeque sua estabilidade.
No próximo texto, falarei sobre o real movimento DevOps.
Márcio Sete é diretor de Marketing e Desenvolvimento de Negócios na especificacoes.com, empresa de gestão de ciclo de vida de aplicações (ALM).