Você está procurando vagas na área de TI pelo Linkedin ou outros sites e se depara com ofertas buscando um profissional chamado de Engenheiro DevOps. Aí, você olha a descrição da vaga e os requisitos parecem mais um monte palavras que não fazem sentido. Puppet, Ansible, Chef, Terraform, AWS, Azure, Azure DevOps, EC2, Kubernetes, Docker, Pipelines, Jenkins, Zabbix, Dynatrace, Nagios, Cloudify, Saltstack, OpsWorks, CI, CD GG, GGWP, OP, X1… Você pensa: ‘minha nossa, eu estava vivendo em um buraco por quanto tempo? O que é tudo isso? Esses caras devem ganhar muito bem, vou descobrir o que é esse tal de DevOps. Acho que é ‘só’ aprender essas ferramentas e dá pra encarar’. Só que não é beeeeeem por aí.

Nesse post vou passar uma ideia mais introdutória do que é o DevOps, porque ele não gira apenas em torno dessa lista infinita de ferramentas, e como, de fato, podemos começar a construir um ambiente DevOps na empresa (alerta de textão).

Mas antes, vamos contextualizar a situação:

A velha história

Pronto, as novas funcionalidades que o cliente pediu foram escritas e os desenvolvedores falaram que está funcionando corretamente. Hora de informar o cliente que vai ser necessário parar o servidor para implantar a nova versão.

Alguém da equipe de desenvolvimento passa a tarde compilando e empacotando o código fonte, depois, avisa a equipe de operações que está pronto para o deploy e repassa o pacote final. Nisso, outra pessoa, que faz parte do time de infra acessa o servidor de produção, muda uma variável de ambiente aqui e outra ali, e enfim faz a publicação do novo pacote… Perfeito, tudo certo. Minutos depois, o caos! Erros aparecem, a API não responde, uma página do front que funcionava já não funciona mais, um relatório traz os dados errados. Em seguida, o cliente liga pedindo para arrumar ‘pra ontem’, já que tudo parou de funcionar depois da última atualização. A infra joga a culpa nos devs, até porque, os servidores estão perfeitos. Os devs jogam a culpa na infra, pois afinal, na máquina deles funcionou, e por fim, o problema leva dias para ser resolvido enquanto o cliente fica com a aplicação em manutenção.

Até que, um belo dia, a empresa contrata um ‘Engenheiro DevOps’ para agilizar e melhorar o fluxo de entrega. São implantados alguns pipelines de integração e entrega contínua utilizando (insira aqui sua ferramenta favorita de CI/CD), e pronto. Show, agora temos DevOps e vamos entregar super rápido! Passado um tempo, o sistema continua apresentando erros em produção, a história do ‘funciona na minha máquina’ ainda continua, dev e infra/ops continuam acusando um ao outro pelos erros e o cliente continua insatisfeito com a demora e falta de qualidade nas entregas.

Mas o que pode ter dado errado? DevOps não era só colocar uns pipelines de automação?

Esse cenário é bastante comum em diversas empresas que produzem software, e principalmente em empresas mais tradicionais que possuem desenvolvimento de ferramentas internas. E vai, infelizmente, continuar se repetindo por muito tempo. A falta de entendimento dos conceitos e ideias por trás do DevOps, e das dificuldades e problemas da área que está ‘do outro lado do muro’ leva, muitas vezes, à má implementação do modelo, ocasionando, quase sempre, perda de tempo e dinheiro.

1. Mas afinal, o que é esse tal de DevOps?

Vamos iniciar do modo mais simples possível, quebrando a palavra em duas partes. DevOps é um termo formado pela junção de outros dois termos bastante comuns, Dev e Ops, que na prática, identificam as equipes envolvidas nas atividades de construção e implantação de um software. Sendo assim, temos os times de desenvolvimento, responsável pela identificação de requisitos com o cliente, análise, projeto, codificação e testes, e também a equipe de operações, responsável pela implantação em produção, monitoramento, solução de incidentes e problemas.

Ok, legal, uma junção das duas áreas, parece simples. Mas, uma pesquisa rápida no Google sobre o termo nos joga uma enxurrada de informações, e após abrir 78 abas no navegador, continuamos sem saber por onde começar.

Vamos pegar aqui uma definição interessante da AWS para DevOps: ‘O DevOps é a combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma empresa de distribuir aplicativos e serviços em alta velocidade, otimizando e aperfeiçoando produtos em um ritmo mais rápido do que o das empresas que usam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura.’

Opa, parece que estamos chegando em algum lugar! Talvez uma outra definição de mercado ajude. Vamos para mais uma (só mais essa, prometo), dada pela Gartner: ‘O DevOps enfatiza as pessoas (e a cultura), e procura melhorar a colaboração entre as operações e as equipas de desenvolvimento. As implementações DevOps utilizam tecnologia, especialmente ferramentas de automação que podem alavancar uma infra-estrutura cada vez mais programável e dinâmica, numa perspectiva de ciclo de vida.’

Filosofias culturais? Enfatizar pessoas? Colaboração? Vish… e agora?

Bom, com base nas definições, vamos considerar que o DevOps é, em suma, uma cultura fortemente colaborativa entre as equipes de Desenvolvimento e Operações para entregar software funcional, de qualidade, seguro estável e confiável. Mais do que apenas um conceito, é importante destacar que o DevOps é um trajeto (em alguns casos bastante sinuoso) de aproximação entre as pessoas, com ações práticas de automação, tendo o objetivo de acelerar as implantações com qualidade, e principalmente, levando em consideração o ponto de vista de todos os envolvidos de maneira respeitosa, algo que conhecemos como a famosa empatia.

2. Um por todos e todos por um

Um dos grandes motivadores para todo o movimento DevOps é que muitas vezes os departamentos tradicionais de TI são normalmente divididos em duas áreas que ficam isoladas e são orientadas por objetivos diferentes. Enquanto o Dev está pensando em aumentar o valor para o negócio, agilidade para inovar e requisitos funcionais, Ops está pensando em proteger o valor para o negócio, estabilidade do ambiente e requisitos não funcionais. Esse conflito de objetivos resulta na criação de um ‘muro’ que dificulta a colaboração entre as equipes e prejudica o resultado final para o cliente. Além disso, ainda podem existir departamentos que executam ações de controle no final do processo para minimizar riscos e impactos negativos. Como exemplo destes departamentos temos segurança da informação, qualidade, governança, compliance, auditoria, entre outros.

Acontece que a dinâmica veloz e competitiva do mercado não permite mais que uma única equipe ou profissional seja responsável pelo controle de qualidade final. A ideia é que todos os envolvidos se sintam proprietários do resultado final que o cliente recebe como experiência na prática.

Sabemos que quando se trata de pessoas, a colaboração é primordial, porém algumas vezes esta acaba sendo negligenciada e influenciada por um ambiente competitivo. É necessário acabar com esta cultura ao herói e da competição negativa e focar em confiança e experimentação, no fim somos todos resolvedores de problemas e em conjunto construímos uma visão mais ampla e diversa alcançando melhores resultados. A ideia é focar em testes automatizados, ambientes padronizados e tomadas de decisões através de fatos e dados com telemetria. Desta maneira todos trabalham juntos, segurança, desenvolvimento, qualidade, design, infra/operações e documentação, e todos seguem alinhados e em prol de um único objetivo: obter a melhor solução.

3. Como aplicar tudo isso na prática?

A melhor maneira de iniciar, definitivamente é analisar o negócio como um todo, verificar processos, verificar como as pessoas e times interagem, como são feitos os testes, como são feitas as entregas, e, a partir daí, definir quais objetivos devem ser alcançados com o DevOps. Queremos melhorar o que aqui? Time to Market mais rápido? Menor lead time entre correções? Aumentar a frequência de deploys? Ter menos falhas em novas releases? Diminuir o tempo entre a detecção de um incidente e sua resolução?

Fonte da imagem.

De qualquer maneira, seja qual for o objetivo, uma coisa é certa, todas as pessoas envolvidas deverão estar preparadas para uma grande mudança cultural, já que, a ideia é que haja a integração de pessoas, processos e ferramentas para transformar a organização em uma única identidade. Essa definitivamente é a parte mais difícil. Apenas implantar novas políticas e procedimentos, apesar de até funcionar inicialmente pode, com o tempo, apresentar falhas - a não ser que a cultura organizacional também acompanhe as mudanças.

Mas claro que é praticamente impossível alcançar todos esses benefícios sem que sejam utilizadas ferramentas para auxiliar nas diversas tarefas que envolvem o DevOps.

Existem no mercado uma grande quantidade de ferramentas para facilitar os processos DevOps. Podemos dividir as ferramentas em diversas categorias e seus respectivos objetivos, sendo elas:

-   Repositórios e versionamento de código: Git, CloudForce, TFS, Subversion

-   Servidores de Build: Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI

-   IAC (Infraestrutura como código): Puppet, Ansible, Salt, Chef, Terraform

-   Automação de testes: Selenium, Cypress, Puppeteer

-   Telemetria: Datadog, Dynatrace, Splunk, Prometheus, Kibana, Nagios

-   Infraestrutura virtual: Amazon Web Services, Microsoft Azure, VMware vCloud, Google Cloud Provider

-   Colaboração e comunicação: Slack, Basecamp, Jira, Pipefy, Trello

Não irei entrar em detalhes sobre o porquê de cada categoria para não alongar demais o post. Fica um assunto para uma continuação.

Cabe a organização encontrar as ferramentas certas para suas necessidades, e claro, possuir profissionais que tenham o ‘know how’ de como utilizá-las em conjunto e de maneira correta.

4. Conclusão

Fazer a mudança de um ambiente de desenvolvimento tradicional para o DevOps é bastante trabalhoso, pois envolve mudanças significativas na organização como um todo. A chave para o sucesso é entender que ferramentas, automação e tecnologias sozinhas não representam o conceito completo de DevOps,  assim como setores, pessoas e times que trabalham apenas no seu quadrado, sem olhar por cima do muro, também não. Tudo, e todos precisam trabalhar juntos levando em consideração conhecimento técnico, respeito, colaboração e empatia.

Referências:

• Amazon Web Services, What is DevOps? Disponível em <What is DevOps? - Amazon Web Services>. 2020
• BERTRAM, Adam. 6 steps to devops success. Disponível em <6 steps to devops success>. 2018
• Buzzword abuse: The anatomy of a DevOps Engineer. 2014
• GARTNER. Definition of DevOps. 2020
• MUNIZ, Antonio et al. Jornada DevOps: unindo cultura ágil, lean e tecnologia para entrega de software com qualidade. Brasport, 2019.