Afinal de contas, o que é DevOps?!
Há alguns anos ouço a palavra DevOps nos corredores dos escritórios, nunca consegui ir atrás para saber do que se tratava. O tempo chegou, a palavra está mais frequente e resolvi arrumar tempo para estudar esse assunto.
Para a minha surpresa, descobri que esse assunto não é exatamente para mim, desenvolvedor. É mais para os diretores. Quando pensei em estudar DevOps achei que fosse estudar uma série de técnicas e ferramentas para facilitar meu trabalho como desenvolvedor e como alguém que coloca sistemas em produção. Mas não é nada disso... Ou melhor, isso é apenas a consequência.
DevOps é um assunto estratégico e não operacional. Tem a ver com cultura organizacional e como as empresas entregam valor. Vou tentar explicar o conceito, partindo da ponta final do processo, o operacional, até o estratégico:
Na maioria das empresas, existe a figura do desenvolvedor e a do administrador de sistemas. Depois que o desenvolvedor escreve o software, ele manda para o administrador. O administrador fica responsável por instalar e rodar o sistema em produção. Esses dois papéis, geralmente, ficam em equipes separadas, com governança separada, processos separados, orçamentos separados e comunicação mais formal. São dois silos separados em que as atividades de um são transparentes para o outro.
Com tamanha distância, o processo para disponibilizar qualquer melhoria no sistema é demorado e é necessário cumprir todo um cerimonial para fazer a esteira de desenvolvimento para produção.
Quando abro um site de notícias e descubro que o Google faz cerca de 5000 subidas em produção por dia, fico achando que é algum milagre. Mas, não é. Eles simplesmente, incorporam o desenvolvimento e a operação em um único processo.
Ao longo dessa década, o Agile se tornou o processo padrão para desenvolvimento de software. Porém, a administração dos sistemas, manteve o processo em cascata. Os desenvolvedores entregam numa velocidade maior do que são capazes de por em funcionamento. Nesses últimos anos, os administradores, interessados na agilidade obtida pelos desenvolvedores, resolveram incorporar essa agilidade em seus processos, também.
Com o surgimento de ferramentas de integração contínua e virtualização (Chef, Puppet, Vagrant, Jenkins, ...), o fluxo (dev -> prod) se tornou muito mais rápido. Através de automação, o Google consegue fazer 5000 deploys por dia. Agora vem a pergunta: fazendo 5000 deploys por dia, como o Google consegue garantir a confiabilidade dos sistemas?
Antes de subir para a produção, é feito uma bateria de testes automatizado em todo o sistema. Para cada funcionalidade, um conjunto de testes é executado. Do notebook do desenvolvedor até os servidores de produção, através de virtualização, todos os ambientes são exatamente iguais. Qualquer problema existente, será acusado rapidamente e o backout será automatizado, também. Dai vem a segunda fase do movimento DevOps. O fluxo inverso (prod -> dev) fornece insumos e controle para os desenvolvedores monitorarem as operações e aprimorarem os seus processos.
Agora vem a parte estratégica. Quando operações e desenvolvedores trabalham de forma bastante integrada e rápida, eles geram insumos para a reflexão e aprimoramento das atividades. O aprendizado se torna uma constante e o ciclo PDCA fica girando, dia-a-dia.
DevOps não é só desenvolvedores+operações. Ele deve ser estendido para uma integração completa da empresa, desenvolvedores+qa+segurançaDaInformação+DBA+operações+usuários. Todos devem estar alinhados em relação a visão da empresa e todos devem ser empoderados e dispostos a aceitar o "errar para aprender". Os processos nas empresa, geralmente, são burocráticos e avessos a riscos mas ao longo do tempo essa estratégia é paradoxalmente a mais arriscada para os negócios. Se sua empresa faz 5 deploys por dia e seu concorrente faz 50, cegamente, digo que ele tem um sistema mais aprimorado.
DevOps não é um cargo, não é uma ferramenta e não é um processo. É uma cultura. É difícil definir DevOps, como dizem, você só vai saber o que é DevOps quando você ver um!