DevOps - Uma Abordagem visual

Gostaria de esclarecer antes de tudo que escrevo esse artigo como uma forma de tornar mais concretas as ideias relacionadas com o DevOps. Eu mesmo estou iniciando meus estudos sobre o assunto mas lembro-me bem que pensei ao ler o PMBOK quão áridas e sem colorido poderiam ser para mim muitos dos conceitos que encontrava alí se não tivesse ao menos tangenciado na vida real do ambiente de trabalho o que significava na prática. Certamente essa distância teria dificultado muito minha preparação para a prova de certificação do PMI.

Esse pensamento foi o que me estimulou a tentar fazer uma abordagem que enriqueça o assunto fazendo comparações relacionadas a elementos comuns à grande maioria das pessoas, mas que possam ajudar aos iniciantes que como eu começam a ter contato com essa cultura.

Neste trabalho não vou repetir as definições formais que certamente podem ser encontradas com facilidade mas vou abordar diretamente o assunto fazendo relação com uma situação hipotética que se nem todos viveram, acredito que seja possível sem grande esforço ser imaginada por todos.

Em primeiro lugar, quero falar sobre a imagem abaixo. Ela é bastante recorrente e tem vários aspectos interessantes.

fonte: blog.mandic.com.br

Foto de Mikhail Nilov @pexels.com

Não menos conhecida é a foto que ilustra o Yin e Yang, que dentre seus muitos significados podemos destacar o equilíbrio entre conceitos aparentemente opostos. Por isso considero particularmente felizes as representações do DevOps que alternam as cores de suas fases e seus nomes. Elas sendo desta forma destacam a complementaridade entre o Dev e o Ops.

O formato que se assemelha a uma lemniscata, o símbolo do infinito. Infinito no nosso contexto é traduzido para contínuo ou melhor dizendo entrega contínua. Essa talvez seja a essência do DevOps. O fato da entrega não ser definitiva, que ela é feita com a expectativa do retorno para que sejam feitas melhorias. Isso gera um senso de responsabilidade para quem entrega pois sabe que aquilo que não for operável como planejado precisará ser revisado.

Fonte: enjoei.com.br

Não foi por acaso que selecionei a foto acima. Quando brincamos com um autorama não temos a expectativa de parar na primeira curva. Queremos girar e girar até nossa mãe nos chamar. e mesmo nessa hora vamos pedir: posso ficar mais 5 minutinhos? Quem nunca? :)

Não foi por acaso também que selecionamos a foto do do site da enjoei. A enjoei tem um modelo de negócio que permite a relação C2C, Customer to Customer, ou seja, de um consumidor diretamente para outro consumidor. Há grandes chances de haver um forte equilíbrio e empatia entre os dois. Embora em papéis diferentes, um sendo o vendedor e o outro sendo o comprador, deveria ser possível essa empatia entre ambos fizesse com que o vendedor explicasse da melhor forma possível como usar o brinquedo, quais as limitações do estado atual em que está sendo entregue. Por outro lado, o comprador deveria considerar as informações recebidas para usar o brinquedo, explicando aos seus amigos como poderiam tirar o melhor proveito dele, evitando assim expectativas frustradas. Ele poderia até, porque não, chamar o vendedor para brincar com ele no futuro.

Considero que o DevOps tenta resolver o grande problema em que o tratar o trabalho de quem projeta e o trabalho de quem opera como totalmente distinto pode gerar em muitas situações. Alguns exemplos:

Um equipamento muito bem projetado mas difícil de ser aberto para fazer sua manutenção.
Um eletrodoméstico que funciona muito bem mas que não tem uma boa documentação explicando seu uso.
Um pintor, que usa uma tinta feita para interiores na parte externa da casa.
Uma pessoa que lava uma roupa na máquina sem observar que a etiqueta indicava a lavagem a seco.

Chego na parte que considero a mais desafiadora para mim. Quero relacionar as fases do DevOps, representadas pelas faixas que se sobrepõem; aliás, esse é o significado original em latim de leminiscata. Proponho que você me acompanhe na história de João Falante:

João Falante está se preparando para dar uma palestra. Ele vai falar de um assunto muito importante para um público muito especial. Esse público não só vai escutá-lo como vai colocar em prática aquilo que ele lhes contar. E mais, eles vão avaliar os resultados e caso identifiquem falhas ou oportunidades de melhoria, sabe o que eles vão fazer? Sim, vão pedir para o seu representante, o Pedro ouvinte contar para o João Falante. João Falante vai ficar triste? Chateado? Amargurado com as críticas e avaliações e propostas de sua audiência? Não, definitivamente não. João vai fazer um novo ciclo e entregar uma nova versão de suas instruções. Querem conhecer como é o processo de trabalho do João Falante?

Planejamento: João Falante pensa no que pretende entregar para sua audiência. Ele então planeja como ordenará o conteúdo. Sua ordem, como será melhor dividir o conteúdo em parágrafos, páginas, capítulos.
Escrita: João Falante começa então a escrever o conteúdo planejado. Ele frequentemente verifica se está seguindo seu planejamento e corrige qualquer coisa que não esteja de acordo com o plano. Da mesma forma, ele corrige o plano quando percebe que na hora de executar algo não funcionou conforme ele esperava.
Formatação do texto: Agora é hora de preparar o texto para que seja lido corretamente pela audiência. Ele verifica a ortografia, escolhe o tamanho e tipo de fonte mais adequado à leitura, faz destaques das palavras mais importantes, inclui figuras, cores e todos os recursos visuais que ajudarão sua audiência a interpretar o texto da forma correta.
Revisão: Esse momento é muito crítico. João Falante pede que algumas pessoas conhecedoras do assunto leiam o material que ele produziu. Caso eles encontrem algo que pode não funcionar muito bem, eles avisarão para o João que prontamente fará as correções necessárias.
Impressão e Expedição: Após acabar a escrita chega o grande momento de imprimir tudo e preparar o material. Ele encaderna os vários volumes, cria os vários pacotes e faz sua expedição.
Entrega: Que alegria, a audiência assiste a arrumação do material e João Falante lê para todos, esclarecendo todas as dúvidas. Todo o ambiente é preparado, sendo providenciado tudo o que será necessário para se obter os resultados esperados.
Execução: A audiência começa a pôr em prática as instruções de João Falante. Caso algo não funcione, eles recorrem ao material recebido e tentam ao máximo obter os resultados prometidos por elas.
Observação: Uma parte da audiência não executa as instruções, eles ficam observando os resultados e após um tempo e algumas reuniões eles resumem tudo o que não funcionou pedindo que seja corrigido ou que algum esclarecimento seja adicionado para que possam obter o resultado esperado.
Planejamento: João Falante então recebe Pedro Ouvinte para saber sobre os resultados. Tudo bem, Pedro Ouvinte fala também. Ele conta o que não ocorreu como planejado. João pode agora começar um novo ciclo de planejamento. Eles combinam em que data uma nova revisão estará disponível, selecionando o que é mais prioritário e se despedem.

E foram felizes para sempre!

Hummm…Hammm… Cenas pós crédito:

Como proposta final gostaria de propor que as 8 fases acima sejam relacionadas com as fases do DevOps. Espero que esse conto de fatos tenha te ajudado a relacionar esses conceitos com uma situação mais próxima de sua realidade e que em breve DevOps seja sua realidade mais próxima. Abraços e até breve:

Planejamento (Plan)
Codificação (Code)
Compilação (Build)
Teste (Test)
Entrega (Release)
Implantação (Deploy)
Operação (Operate)
Monitoração (Monitor)

FIM