Sua ferramenta de CI/CD não é DevOps!
Quando comecei pensar nesse artigo, abordando o tema DevOps, me deparei com a seguinte situação: Todo mundo fala o que é DevOps, falam sobre ser mais cultura que ferramenta, ser uma filosofia, um modo de trabalho colaborativo, e tudo isso é verdade. Mas o que pouco se fala é o outro lado: O que não é DevOps?
É muito comum empresas e ferramentas distorceram um pouco a simplicidade do DevOps. E o que era pra ser simples, acaba se tornando algo assustador, que depende até mesmo de especialistas para acontecer (o que vai na contra mão dos conceitos de DevOps).
Então, de forma simples, o que é DevOps?
DevOps é a união entre desenvolvimento e operação, com um objetivo em comum: Colocar software funcionando em produção, o mais rápido possível, de forma continua.
E?
Sabendo que nosso objetivo com DevOps é unir desenvolvimento e operação para colocar software funcionando em produção de forma continua. Então por que existem coisas como:
- Cargo DevOps
- Ferramentas que prometem fazer DevOps
- Curso de DevOps
- Certificação DevOps
E essa lista vai longe...
Os fatos
De fato, cargo DevOps, ferramenta que faz DevOps, não fazem sentido algum se pensarmos nos princípios em si. Então, é possível afirmar que esses pontos levantados acima, não são DevOps em sua essência? Sim, é possível.
Lá nos primórdios, quando surgiu o Sistema Toyota de produção, a base do que é a filosofia do DevOps nasceu junto com várias outras coisa como o SCRUM, o XP e outras frentes do ágil. Essa base está descrita em praticamente todos os princípios do ágil. Logo, é possível entender que DevOps é desenvolvimento de software utilizando princípios do ágeis.
Então o cargo DevOps não faz sentido?
Algumas empresas contratam um "DevOps" na expectativa de ele criar automações, construir pipelines e eventualmente fazer integrações em nível de infraestrutura, e isso está totalmente errado, inclusive, vou além: Não só está errado, como você está destruindo sua equipe de desenvolvimento de software. Eu explico:
- Se a proposta é unir desenvolvimento e operação, porque colocar toda a responsabilidade em apenas uma pessoa?
- Se uma pessoal é responsável por DevOps, pipeline e integrações, o que acontece com o produto se essa pessoa sair da empresa ou estiver de férias?
- Se tem um responsável único, quando vai existir a oportunidade de gerar integração entre desenvolvimento e operação?
- Como fazer nascer o espírito de dono, se a equipe não é responsável por tudo?
- Como aproveitar para otimizar a equipe se trabalham de forma individual e não compartilham conhecimento entre eles?
Pode existir um Cargo DevOps, mas esse seria o profissional que iria apoiar o time para que o time trabalhasse na construção de suas pipelines, o time iria debugar e colocar a mão em todas as ferramentas necessários para que o software chegue em produção de forma sustentável, o time seria questionado por esse profissional a avaliar constantemente os métodos e ferramentas que utiliza, e esse profissional também seria a pessoa que iria observar se o time é multi-funcional o bastante para atender aquilo que se propõe a atender, e buscar soluções junto a outros papéis, como Scrum Master, caso fosse necessário.
Mas só o cargo é um problema?
Além do cargo, falei sobre ferramentas, e é importante saber que ferramentas são apenas formas de acelerar a entrega de software e não tem nada a ver com os princípios do DevOps.
Existem aqueles que vendem "Soluções DevOps" (um aglomerado de ferramentas e que muitas vezes são casados com trabalho de consultores configuraram essas ferramentas), e o time que deveria compreender e ser engajado nos princípios DevOps, acaba apenas virando um usuário de um setup feito por um consultor (que também será acionado em manutenções ou incidentes).
E o que mais?
Os outros dois pontos que mencionei, são Cursos e Certificações. E é importante observar com cuidado essa última parte pois existem cursos e certificações que ajudam as pessoas a entenderem que DevOps é mais cultura do que ferramenta, e o oposto desse objetivo é que classifico como "desnecessário".
Conclusão
Se você acha que DevOps já é uma realidade pra você, faça os questionamentos abaixo para você e para sua equipe:
1) minha equipe consegue colocar software funcionando em produção, com agilidade, a todo instante, sem depender de ninguém?
2) minha equipe olha para os processos de entrega de software buscando aprimora-los constantemente?
Se em ambas você respondeu sim, parabéns, você realmente trabalha em um time que "faz" DevOps. Do contrário, não!
Um ponto que mencionei no texto, mas não expliquei, é quando digo: colocar software funcionando em produção. Tive o cuidado de sempre usar a palavra "funcionando" para enfatizar de que colocar o software em produção, usando pipeline automatizado, mas sem funcionar como deveria, é o pior dos cenários.
Se você e sua equipe possuem oportunidade para aplicar DevOps, aproveite.