DevOps: o que é e porque é tão importante?

por Daniel Silva

DevOps é uma palavra que ouvimos cada vez mais. Mas por que motivo? É só algo do momento? Qual é a utilidade? É um título? É uma cultura? Vamos alinhar estes conceitos! DevOps é a contração de duas palavras: Development e Operations. Há muita divergência sobre o que é na realidade DevOps e, na verdade, pode representar uma cultura, um título/posição, uma metodologia, um conjunto de ferramentas. Há ainda quem diga que é uma palavra que está na moda só para descrever algo que já se fazia antes.

Pessoalmente, considero que é uma junção dos quatro primeiros pontos. Neste artigo vou explicar o que é DevOps e como implementar.

Cultura

Utilizar/implementar práticas DevOps implica uma adaptação na forma de trabalhar, pensar e agir. Pode quase ser visto como um ritual ou, neste caso, uma cultura construída com base em AGILE, teoria de sistemas, empatia, responsabilidade e colaboração.

Título/posição

Existe efetivamente procura para posições de DevOps. Por norma, esta procura é para integrar equipas dedicadas a ajudar as diferentes equipas/áreas em todos os processos que vão desde o desenvolvimento, à manutenção, entrega ou comunicação, recorrendo às mais variadas ferramentas e metodologias. Estas equipas são importantes porque criam rigor e forçam as boas práticas, elevando assim a qualidade do produto final. Além disto, permitem que cada equipa se foque no seu objetivo, sem terem de se preocupar em como é que vão automatizar processos.

Metodologia

Como o nome indica, metodologia é a aplicação de métodos. DevOps baseia-se muito na aplicação de métodos. Métodos para automatizar processos, auxiliar as equipas, monitorização, geração de infraestrutura, entre outras coisas. Tal metodologia em DevOps tem ainda como objetivo integrar o trabalho de desenvolvimento de software com as suas operações, promovendo assim uma cultura de colaboração e responsabilidade partilhada entre equipas.

Do desenvolvimento à implementação do software, DevOps tem como finalidade promover a eficiência em todo o processo. Assim, as equipas podem melhorar a qualidade do seu código, fazer com o que a solução chegue mais rapidamente ao mercado e, consequentemente, envolver toda a equipa para um melhor planeamento da aplicação no futuro. Na sua génese, a metodologia de DevOps está assente em quatro princípios:

• Automação do ciclo de vida de desenvolvimento de software
• Colaboração e comunicação
• Melhoria contínua e minimização do desperdício de tempo
• Foco nas necessidades do utilizador, com ciclos de feedback curtos

Conjunto de ferramentas

Ao longo do tempo têm surgido cada vez mais ferramentas e bibliotecas para auxiliar na aplicação destas metodologias. Alguns exemplos são as pipelines, containers, Kubernetes, Terraform entre muitos outros.

Por que razão não é só uma nova palavra para definir algo que já se fazia?

Quem defende este ponto normalmente diz que “sempre houve estratégias de desenvolvimento e integração”. Nota que risquei a parte das estratégias porque normalmente é desta parte que se esquecem. E mesmo em casos em que há estratégias, estas muitas vezes não são práticas – são manuais, o que faz com que sejam propícias a erros. É aqui que entra o DevOps!

Mas afinal, o que é que faz um DevOps Engineer?

Quando alguém da minha área, seja developer, gestor de projeto, chefe de equipa, etc. me pergunta o que é que eu faço como DevOps Engineer, respondo sempre com a seguinte pergunta: “Como é que a tua equipa lida com passagens a produção?”.

Muitas vezes ficam confusos e não percebem porque é que respondi com uma pergunta que em nada responde à deles. Mas esta pergunta é feita por uma simples razão: um dos grandes cenários em que DevOps cria (bastante) impacto é na redução do esforço/trabalho necessário nas passagens a produção. Isto faz com que seja um excelente ponto de entrada para explicar/demonstrar porque é que DevOps está “tão na moda”.

Um cenário prático que reflete a realidade

Várias vezes, a resposta à minha pergunta é algo deste género:

“Agendamos a passagem a uma determinada data. Quem está responsável pela passagem nesse dia compila o código, corre os testes, prepara as configurações, publica o código, aplica as configurações e faz uns testes para garantir que está tudo operacional”.

A minha reação costuma ser mais ou menos assim:

E quando pergunto quanto tempo demoram estas passagens, a resposta é que costuma depender da complexidade da aplicação/componente. Mas, se tudo correr bem e ninguém se enganar em nenhuma configuração, até é pouco tempo… um par de Horas.

Novamente, a minha reação:

Este processo é custoso em vários sentidos:

• O processo de compilar o código e correr os testes pode demorar bastante tempo, e normalmente corre na máquina de quem vai fazer a publicação, o que pode tornar a mesma inutilizável durante este período
• Essa pessoa (muitas vezes até envolve mais que uma pessoa) tem que fazer uma compilação de configurações a alterar e apontar tudo para que o possa fazer depois de publicar
• A probabilidade de haver uma falha/esquecimento de configurações é diretamente proporcional à quantidade e complexidade das mesmas, o que vai implicar mais tarde fazer um despiste em caso de erro;
• Terá de haver alguém (seja quem fez o levantamento ou outra pessoa) a aplicar as alterações necessárias, o que consome ainda mais tempo a essa pessoa e a todo o processo.

E não nos podemos esquecer de que estamos a falar de uma passagem para o ambiente de produção. Significa isto que (a não ser que haja algo de muito errado no processo da equipa, mas isso é outro tema), para isto ir para produção, estas configurações já tiveram que ser feitas em pelo menos outro ambiente! Se considerarmos que muitas equipas utilizam 3 ambientes: Desenvolvimento, Qualidade e Produção, estamos a triplicar o tempo necessário.

No caso anterior, se considerarmos o cenário otimista (um par de horas), significa que quem for fazer a passagem entre ambientes vai gastar no total 3x2horas = 6 horas, e isto se tudo correr bem!

Como é que DevOps é útil neste caso

Existem várias vertentes que podem ser melhoradas. E o melhor disto tudo é que as melhorias podem ser graduais e adaptativas. Significa isto que podemos começar por pegar nos pontos que são mais demorados e ir melhorando.

O objetivo final é tentar automatizar o máximo para que a intervenção seja mínima e a probabilidade de erro seja reduzida ao máximo. Assim sendo, o nosso objetivo é ter uma pipeline que faça todo este processo: compilar o código, correr os testes, gerar o artefacto, publicar o artefacto nos diferentes ambientes, assim como as configurações necessárias.

Pipelines

De uma forma muito simplificada, uma pipeline permite-nos executar um fluxo definido por nós. Indo por partes:

• Poderíamos começar por definir a compilação e execução dos testes e, se tudo estiver em conformidade, gerar o artefacto no final. Assim bastava-nos descarregar o mesmo e publicar para cada ambiente. Isto já permitia compilar e executar os testes fora da máquina do developer, libertando-o assim para continuar a trabalhar
• De seguida, evoluíamos o nosso fluxo para poder publicar para diferentes ambientes, sem termos que descarregar o artefacto e fazê-lo manualmente
• Relativamente às configurações, poderíamos utilizar ferramentas de automação tais como Terraform, Ansible, Puppet, etc. consoante as necessidades para definir as configurações e integrar as mesmas na nossa pipeline

Ainda que tudo isto tenha uma curva de aprendizagem gradual e o setup inicial seja demorado, o tempo que se ganha daí para a frente é incalculável.

A minha experiência

Quando comecei a trabalhar como DevOps Engineer, tudo era novo e era um mundo com imensas possibilidades e diferentes ferramentas que permitiam atingir o mesmo objetivo. A equipa que integrei tinha um padrão muito semelhante ao que descrevi: os processos eram maioritariamente manuais, as configurações não eram centralizadas, era preciso juntar diferentes pessoas/equipas para analisar o que era preciso alterar e muito mais. Inicialmente acompanhei passagens que para o ambiente de produção demoravam 2 ou 3 horas.

Atualmente temos mais equipas e mais projetos, no entanto as nossas passagens (para três ambientes demoram cerca de 15 minutos), e normalmente existem apenas 2 intervenientes: quem está responsável pela passagem, e uma segunda pessoa que faz uma revisão para confirmar se está tudo bem e aprova a passagem para o ambiente de produção.

Conclusão

Existem diversas partes/áreas em que DevOps causa um grande impacto. O exemplo que te trouxe hoje é um dos que considero dos mais impactantes e fáceis de explicar para mostrar a diferença entre empresas/equipas com e sem práticas de DevOps.

Pessoalmente, é bastante gratificante e satisfatório automatizar os processos onde sei que as equipas têm mais dificuldades ou perdem mais tempo, pois sei que estou a tirar-lhes carga de cima, estamos a reduzir a probabilidade de erro, e todos ganhamos com isso.

Como disse inicialmente, não acho que seja apenas um nome para definir algo que já se fazia. Acredito que, cada vez mais, existe a necessidade de seguir estas boas práticas e automatizar o máximo possível, pois os resultados são facilmente visíveis.

Mas também é importante termos em conta que isto é um processo constante e evolutivo. A indústria está a evoluir a uma velocidade estonteante e há cada vez mais ferramentas, tecnologias e técnicas para resolver os problemas.

Sabe mais sobre DevOps no webinar on-demand “DevOps Azure: da cultura à prática“