O site da Oracle define DevOps como “uma combinação de duas funções que normalmente são tratadas separadamente: desenvolvimento e operações”. Também diz que é uma “metodologia de desenvolvimento padronizada, comunicação clara e processos documentados suportados por uma plataforma de middleware comprovada e baseada em padrões melhoram o desenvolvimento de aplicativos e os ciclos de gerenciamento, trazem agilidade e fornecem maior disponibilidade e segurança para sua infraestrutura de TI”.

E aí a gente e pergunta: e daí? O que tudo isso significa na prática?

Se você leu o post sobre como um aplicativo é criado, deve se lembrar de que há pelo menos duas equipes envolvidas neste processo: os desenvolvedores (programadores), que criam o código e a base de dados dos aplicativos; e o pessoal de infraestrutura ou de Operações de TI, que coloca o aplicativo no ar e deixa-o disponível para os usuários. Atenção! Não confundir com a área de Operações da organização, que cuida de seus processos e recursos gerais; ou com a área operacional, que agrupam os funcionários que atuam nas atividades e rotinas de base.

Em algum momento, os desenvolvedores passam o aplicativo para equipe de operação subir para produção – ou colocar no ar. E aqui podemos ter problemas.

Uma ocorrência típica é a falta de bibliotecas. Já aconteceu comigo: uns amigos vieram a uma festinha em minha nova casa e trouxeram uma garrafa de vinho. Eu, recém mudada, não tinha nem saca rolhas, nem taças adequadas. Imagine que os desenvolvedores chegam com um aplicativo que usa uma biblioteca de gerar PDFs e o servidor de produção não tem essa biblioteca instalada ou – pior – tem alguma incompatibilidade com ela.

Para evitar esse tipo de ocorrência, é necessário que as duas equipes se conversem por meio de documentação. E qual desenvolvedor gosta de documentar? E quem disse que ele sabe o que deve documentar? E como impedir que essa documentação vire simplesmente uma burocracia e não seja lida por ninguém?

Outro exemplo: recentemente desenvolvemos uma ferramenta para controle de auditoria de equipamentos em um hospital. Eram mais de 4.000 itens a serem auditados mensalmente e, em cada controle, recebiam de cinco a quinze páginas de relatórios escaneados, em formato de PDF. Cada arquivo tem em média 10Mb, o que representa mais 40Gb mensalmente no servidor do hospital ou 0,5Tb por ano.

Esse volume pode não parecer grande coisa quando falamos de megaempresas de dados, mas para um hospital de médio porte, isso pode ser problema.

A área de Operações de TI é do hospital e todo o desenvolvimento é feito pela nossa consultoria. Temos um checklist para implantação que inclui a verificação da oscilação de dados em produção. Como nossa estrutura é de pequeno porte, nossa metodologia é simples em comparação às de outras grandes desenvolvedoras, mas funciona e executa bem esse trabalho de passar o bastão para a área de Operações de TI.

O DevOps aumenta a qualidade das implantações, diminuindo problemas de comunicação e de requisitos. Ao reduzir erros, agiliza a entrada do aplicativo em produção e aumenta a segurança. Por fim, ter um método para a passada de bastão permite que desenvolvimento e operação precisem se preocupar menos com o que “têm que lembrar” para a implantação e possam focar no que realmente importa: o produto.

A área de DevOps tem muitas ferramentas e processos já pré-montados – leia metodologias ou estruturas (frameworks), dependendo de quem apresenta – que ajudam no desenho e implantação em uma empresa. Olhando algumas delas, parece fácil e direto implantar. Mas há alguns empecilhos e muitos deles são culturais. Mas isso é assunto para outro post. Até a próxima!