DevOps, de novo não :(

Parte 1: Por que todos insistem em adotar DevOps?

Você é um desenvolvedor de software, certo? Com quantos anos de experiência? Talvez dois ou três, ou um veterano como eu, com mais de trinta anos, não importa. Você deve ser constantemente bombardeado com novidades todos os dias, um novíssimo framework revolucionário, outra linguagem de programação ou um novo serviço de nuvem que acaba de sair do forno e promete fazer tudo que seu código faz por uma fração de centavo e é claro, sobre tudo isso as metodologias, paradigmas e os movimentos culturais.

Se você acha que tudo isso não contribui em nada com o seu dia-a-dia, pode ser que esteja correto, afinal você é fluente numa linguagem de programação largamente utilizada, entrega funcionalidades com boa qualidade e no prazo e seus usuários estão satisfeitos e nem querem saber o que tem por trás, desde que funcione, certo?

Bem, se essa é a sua realidade, pode parar de ler agora! Sério, obrigado pela atenção. Mas, se esse não for o caso, sugiro continuar.

Se seus usuários estão insatisfeitos, provavelmente isso não é sua culpa, ou pelo menos não só sua. Usuários ficam insatisfeitos por vários motivos e, na maioria das vezes, a frustração está relacionada com as expectativas, que são:

• Funcionalidades: Esperavam que a aplicação funcionasse de outra forma, ou que pelo menos funcionasse;
• Prazo: Me prometeram para essa semana.

De fato, não são tantos motivos assim para os usuários. Requisitos funcionais e não-funcionais são funcionalidades e não importa o motivo, se não dá para usar na data que ele esperava, não está pronto.

Isso nos leva à questão:

Por que todos insistem em adotar DevOps?

DevOps resolve esses problemas, certo? Não realmente. Problemas com expectativas são mais bem resolvidos com métodos ágeis, você sabe, envolvimento do usuário com a equipe, entregas frequentes e constantes, priorização do que precisa ser feito, essas coisas. Então por que DevOps?

Para responder, precisamos definir DevOps. Isso mesmo, nossa própria definição de DevOps! Como o termo não pertence a uma instituição específica, há várias definições e eu gostaria de propor uma que li há algum tempo e adaptei:

DevOps, em última análise, significa construir fluxos digitais de trabalho que levem o código da máquina do desenvolvedor até um excelente produto gerador de valor [1].

Ok, pode parecer simplista, mas na prática, toda a definição cultural de DevOps serve para definir processos e papéis. Há excelentes livros, se você quiser entrar mais no lado cultural, mas no que diz respeito ao código, é isso. Vamos quebrar a definição e discutir um pouco:

• Construir fluxos digitais de trabalho: Também conhecidos como pipelines, significa automatizar todos os passos, desde o armazenamento do código em repositórios, controle de versão, compilação, testes unitários, avaliação de qualidade de código, segurança, empacotamento e distribuição. E digital, claro que sim! O que somos? Homens das cavernas? Desenvolvedores escrevem código e é redundante chamar de “as a code”, afinal tem outro jeito?
• Da máquina do desenvolvedor: Não acredito que isso aconteça nos dias de hoje, mas como disse, sou veterano e no início da minha carreira era muito comum ver código que ficava grudado na máquina do desenvolvedor: só existia lá, só rodava lá e só era mantido pelo dono da máquina. Hoje em dia, a máquina do desenvolvedor é um ambiente transiente e muito parecido com o destino do código. Em muitos casos, uma imagem que pode ser executada em múltiplas plataformas. E as múltiplas versões do código, binários e os processos para sua geração residem em repositórios compartilhados com toda a organização.
• Excelente produto gerador de valor: Ok, você não controla a parte do valor, ou será que controla? Um defeito ou uma má qualidade do código pode levar à perdas de valor, mesmo que o conjunto de funcionalidades seja excelente. O que você controla é a qualidade do código e o tempo. Um bom produto para o dia das mães não vale muito no natal, certo?

Como você pode perceber, DevOps pode ser interpretado de várias formas, o que na minha opinião não é bom. No final das minhas contas, é a automação de bons processos de construção de software de qualidade e o engajamento de todos nesses processos.

E então, por que adotar DevOps? Porque é a forma profissional de entregar software e se você ainda não está convencido, deixe seus pensamentos nos comentários.

Software se tornou essencial para as nossas vidas, está em todos lugares. Em crises, como a Covid-19, se torna essencial para a continuação das nossas atividades produtivas e sociais. Nossa responsabilidade como profissional nunca foi tão grande e nunca fomos tão valorizados quanto agora. Somos muitos e ainda assim poucos para tudo que pode e precisa ser feito. Manter um processo de qualidade para entrega do nosso trabalho é nossa responsabilidade e obrigação como escribas modernos.

Na parte dois iremos tratar de como implementar o que discutimos aqui.

Vida longa e próspera.