A cultura DevOps, mais do que ferramentas

Como começou DevOps?

O movimento DevOps começou há mais de 10 anos. Patrick Debois tentava aplicar a mentalidade ágil à infraestrutura que administrava, embora sem muito sucesso. Mais tarde, conheceu Andrew Clay Shafer, que trabalhava na ideia de infraestrutura ágil, e Jean-Paul Sergent, que explorava formas de melhorar a colaboração entre as equipes de desenvolvedores e as equipes de operações de TI.

Planejaram compartilhar suas ideias em uma conferência. Em 2009, Debois assistiu a uma palestra do Flickr sobre a cooperação entre desenvolvedores e operações para realizar múltiplos deploys por dia em produção. Isso o motivou a organizar uma conferência em Ghent (Bélgica). Chamar de "Administradores de sistemas ágeis" não parecia o nome mais atraente para a conferência, e acabou sendo chamada de "DevOpsDays".

Atualmente, você pode procurar por trabalhos de "DevOps" e encontrar uma ampla variedade de habilidades requeridas e de funções. Algumas vagas se concentram em Terraform ou Ansible, outras se assemelham mais a um arquiteto Cloud da AWS ou a um especialista em Docker/Kubernetes, mas poucas falam de uma mentalidade DevOps. O próprio Patrick Debois publicou um esquema sobre os papéis DevOps em seu blog:

Desde a conferência que cunhou o termo DevOps, a quantidade de ferramentas associadas cresce dia a dia. As ferramentas captam toda a nossa atenção na maior parte do tempo. No entanto, a colaboração entre desenvolvedores e operações é o pilar da mentalidade DevOps com o objetivo focado na entrega contínua.

Estrutura da equipe DevOps

Normalmente, cada equipe na mesma empresa tem diferentes responsabilidades, por isso suas prioridades e objetivos são diferentes. Isso gera gargalos e atrasos nas entregas de novas funcionalidades. E esta é uma das causas fundamentais que originaram o movimento DevOps.

A relação entre as equipes no contexto DevOps foi analisada por Matthew Skelton em 2013 em “DevOps Topologies”. Aqui você pode encontrar uma das formas mais comuns de acelerar as entregas: criar uma equipe de DevOps especializada em automação e CI/CD. Embora seja necessário ter cuidado, pois está categorizado como um antipadrão, já que essa equipe pode se tornar um silo (e DevOps trata-se de quebrar silos, certo?).

Este estudo sobre o trabalho entre equipes (não apenas DevOps) evoluiu com Manuel País e juntos escreveram o livro “Team Topologies” onde analisaram as diferentes formas de estruturar equipes para o desenvolvimento de software.

No livro, apresentam diferentes padrões para organizar as equipes e também descrevem as forças ocultas que impulsionam as relações entre as equipes.

Um dos muitos pontos-chave do livro é o conceito de carga cognitiva. Uma pessoa é capaz de reter uma determinada quantidade de informação para realizar uma tarefa. E o mesmo vale para uma equipe.

Agora imagine uma equipe que trabalha com uma grande quantidade de ferramentas ou uma equipe que lida com muitas responsabilidades diferentes (ou ambas). Inevitavelmente, aparecerão atrasos e gargalos devido a contextos mutáveis, dedicação multitarefa ou dias cheios de reuniões. Novamente, a motivação DevOps é eliminar qualquer atraso para alcançar um fluxo rápido. O livro dá indicações sobre como enfrentar essas situações.

O que será o próximo?

Depois de uma década desde que DevOps começou em 2009, o desenvolvimento de software evoluiu: computação em nuvem, infraestrutura como código, microsserviços, docker, kubernetes…

Então, o DevOps ainda é relevante ou se tornou outra palavra da moda vazia? Talvez possamos ouvir Kris Buytaert falando sobre isso no DevOps Barcelona 2022. Enquanto isso, recomendamos que você leia:

• “13 anos de devops e 130 apresentações depois: como mudou meu modelo mental de devops” de Patrick Debois
• “De Devoops a Devops, 10 anos de aprendizado” de Kris Buytaert