DevOps, colocando a ponte entre desenvolvimento e operações

Onze anos após o Manifesto Ágil e muito mais anos de melhorias contínuas nas práticas de desenvolvimento de software resultaram em um grande impacto na nossa indústria. Práticas como Desenvolvimento Orientado a Testes (Test Driven Development, ou simplesmente, TDD) e Entrega Contínua (Continuous Delivery) permitiu que times de desenvolvedores desenvolvessem melhores softwares e de forma mais previsível. Mas ainda restava uma lacuna - entre operações e desenvolvedores - DevOps é a ponte que nos permite saltar essa lacuna.

Entra DevOps

DevOps é, de acordo com Stephen Nelson-Smith, um “movimento de pessoas que pensam que é hora de mudança para a indústria de TI - hora de parar com o desperdício de dinheiro, hora de começar a entregar software excelente e para construir sistemas que escalam e duram”.

O movimento tem raízes nos movimentos de Infraestrutura e Operações Ágeis que estavam aplicando as práticas de engenharia Ágeis para melhorar a Entrega Contínua. Estes movimentos foram uma resposta a um problema identificado, que era o fato de que as organizações que estavam desenvolvendo software com métodologias Ágeis caiam para uma metogologia waterfall (cascata) quando era hora de implantar o software desenvolvido.

Essa fronteira entre o processo waterfall é o que Andrew Shafer chama de círculo da felicidade e parede da confusão. Basicamente o time de desenvolvimento (desenvolvedores, testadores e product owners) ficam dentro deste círculo com feedbacks regulares entre as iterações e comunicação fácil. Mas a comunicação com pessoas de fora deste círculo é desastrada e isto trás uma série de problemas que afetam a entrega de valor.

Stephen também define quatro problemas que a nossa indústria de software lida hoje que o DevOps pode ajudar a eliminar ou mitigar: medo de mudanças, implantações arriscadas, “funciona no meu computador” e silo-ização¹. O medo da mudança leva a processos de gerenciamento burocráticos que faz com que qualquer mudança na aplicação (seja a introdução de uma nova funcionalidade ou uma correção de bug) leve um longo período tempo para ser concluída. Implantações arriscadas prejudicam especialmente os times de desenvolvimento e operações já que isso pode levar a implantações em horários calmos - muitas vezes na madrugada, ao qual pode queimar muita energia dos times - porque não há confiança no software a ser implantado.

Funciona no meu computador! é um cliché. Quem nunca presenciou um problema que ocorre em produção e que quando fora reportado aos desenvolvedores estes responderam: “funciona no meu computador!”? Não é incomum encontrar times de desenvolvimento usando diferentes sistemas operacionais e/ou o ambiente de dependências do software em versões diferentes do ambiente de produção. Isto pode levar a suposições enganosas baseadas nas diferentes funcionalidades disponíveis nas diferentes camadas que compõe a pilha de dependência do software - ao qual é especialmente evidente quando os desenvolvedores não conhecem a infraestrutura.

E o problema notório com times em silos diferentes é a cultura de “apontar o dedo” e a mentalidades “nós e eles”. O círculo da felicidade de Shafer é muito sobre este problema: os silos diferentes tem medo um do outro, eles colaboram e comunicam-se mal.

Mudanças culturais

DevOps é muito sobre mudança de cultura já que aplica muitas das lições aprendidas com as práticas de Desenvolvimento de Software Ágil. Uma das lições é sobre comunicação e colaboração. DevOps reduz as fronteiras entre desenvolvimento e operações ao construir um time multidisciplinar com pessoas que, como Stephen destaca, “sentem-se confortáveis com infraestrutura e configução, mas também felizes por arregaçar as mangas, escrever testes, debugar e entregar funcionalidades”.

Colocar desenvolvedores e operações juntos significa dar-lhes oportunidades para descobrirem melhores formas para entregar melhor software. Isso propaga a corrente de valor de negócio que é bem conhecida no círculo da felicidade para o time de operações, que começa a ser visto como parte da solução ao invés de apenas ser visto como responsável por manter os servidores 24x7. Isto preenche a lacuna que estava faltando nas metodologias Ágeis: faz com que operações fiquem em sincronia com o processo de desenvolvimento, alinhando os times de desenvolvimento e operações com um processo de negócio unificado.

Certamente não é fácil ir de um time de operações caixa preta para um time totalmente DevOps. É difícil encontrar pessoas com esta mentalidade multidisciplinar. Mas DevOps, como Mitchell Hashimoto diz, não é algo absoluto e sim uma escala. Você não precisa procurar ter um time onde os desenvolvedores fazem todas as operações, você precisa procurar a sua forma de fazer DevOps. É mais sobre identificar pessoas que podem ser as pontes entre desenvolvimento e operações, encorajando-as e dando-lhes autonomia para que elas o façam.

Citando Stephen novamente, DevOps “tem um tremendo impacto nos negócios. De repente o time técnico começa a tentar trabalhar como um só. Uma mentalidade de ‘todos a bordo’ emerge, com todas as pessoas técnicas sentindo-se capazes de ajudar em todas as áreas. As áreas tradicionalmente problemáticas de implantação e manutenção quando em produção tornam-se tratáveis - e os campos de batalhas chave dos desenvolvedores (‘o sysadmin construiu uma plataforma não confiável’) versus sysadmins (‘os desenvolvedores escreveram código não confiável’) começa a transformar-se em uma aproximação interdisciplinar para maximizar a confiabilidade em todas as áreas. Isto tem, claro, um efeito positivo no final - melhor confiabilidade e disponibilidade, clientes mais felizes, menor tempo de lançamento para o mercado, e mais tempo para focar a energia do time no negócio principal do que a desperdiçando em administração ou apagando incêndios” (ênfase minha).

Ferramentas

Além das mudanças culturais, DevOps é carregado de boas práticas Ágeis aplicadas na infraestrutura. Uma grande mudança é o conceito de infraestrutura em código. Com DevOps, tudo deve estar no controle de versão - da configuração de rede à configuração das aplicações. Não há DevOps sem controle de versão já que esta é a base para todas as outras práticas. Como software, a infraestrutura deve ser construída a partir do código-fonte e igualmente tratada como uma aplicação.

Construir do código-fonte significa ter serviços online a partir de um servidor “limpo” através de um processo automatizado. Os sistemas de gerenciamento de configuração são muito úteis aqui: eles colocam um sistema em um estado conhecido usando a configuração que fica disponível no controle de versão e ajudam a alcançar consistência no ambiente de TI. Ele possibilita que operações gerenciem o ciclo de vida dos servidores, provisionando novos servidores pelo objetivo de seus serviços, de forma semelhante a aplicação de templates, dando aos servidores responsabilidades como “Servidor de Banco de Dados”, “Servidor de Cache HTTP” ou “Servidor de Aplicação”.

Existem alguns sistemas de gerenciamento de configuração open source disponíveis, sendo o Puppet e o Chef os mais conhecidos. Você pode encontrar muitos casos de uso interessantes de ambos os sistemas. Tumblr (a popular plataforma de blog), por exemplo, usa Puppet para atualizar os computadores dos desenvolvedores. Travis CI (o serviço de Integração Contínua hospedado) usa Chef para construir as imagens dos workers de Integração Contínua que são responsáveis por executar os testes de dezenas de milhares de projetos open source.

Esse tipo de gerenciamento de servidores otimiza operações ao prevení-la de realizar a configuração manual dos servidores, o que leva a incosistência entre servidores com serviços semelhantes e previne a ocorrência do que Shafer chama de “Máquina Misteriosa” - um servidor que ninguém sabe o que executa e que todos tem medo de desligar. Outro aspecto importante desses sistemas é a idempotência - nesse contexto, a habilidade de aplicar o template² de configuração na mesma máquina várias vezes sem modificar o resultado final, que é a máquina configurada como descrito no template.

Outras ferramentas são igualmente úteis. Uma delas é o Vagrant³, que é uma ferramente que facilita a criação e configuração de ambientes virtualizados. Com o Vagrant você pode, por exemplo, criar uma máquina virtual com um ambiente o mais semelhante possível do ambiente de produção para ser distribuída no time. Esta é uma ferramenta realmente importante para fazer da frase “funciona no meu computador” uma desculpa do passado. O Vagrant também é usado como um sandbox para testar templates de sistemas de gerenciamento de configuração como Puppet ou Chef. Você também pode usar scripts shell para configurar o seu ambiente.

Os avanços das tecnologias de virtualização também possuem um papel importante para alcançar melhor qualidade e entrega de software. Aproveite a computação em nuvem quase ubíqua para rapidamente prover ambientes de desenvolvimento, teste, staging e produção tão semelhantes quanto possível para o seu time.

Mas, lembre-se, mais importante que as ferramentas é a criação da cultura. Crie um time com habilidades interfuncionais e envolva-o nas atividades de implantação. Faça da implantação uma atividade que tanto desenvolvedores e operações possam fazer facilmente e em qualquer hora. Como o código-fonte de seu projeto, faça da sua infraestrutura uma propriedade coletiva e encontre a sua maneira de fazer DevOps em passos de bebê⁴.