M1: Olá, pessoal. Bom dia, boa tarde e boa noite. Vamos começar mais um episódio dos Agilistas. Hoje estou mais uma vez com o Chagas.

M2: E aí, galera.

M1: Mateus.

M3: Pessoal, bom dia, boa noite e boa tarde também.

M1: E Felipão.

M4: Fala, pessoal, beleza?

M1: Hoje a gente quer continuar uma série, que começou com Testes de Automatizados. E conforme eu falei naquele episódio, a gente quer trazer alguns temas para aumentar o conhecimento técnico de quem está participando dessa transformação digital, e dessa transformação cultural de trazer o Agilismo para dentro da empresa, por achar que esses temas são extremamente relevantes. E que não se pode mais ficar ignorante sobre eles, muito menos intencionalmente ignorante. O tema que a gente quer trazer hoje, é um tema muito importante para que o Agilismo possa realmente se materializar, quando a gente fala especificamente de Agilismo se materializando com Software. A gente sabe que o Agilismo é tanto de coisas, mas pensando na transformação digital, e na necessidade da empresa de fazer experimentação com Software o tempo todo, um tema que está muito atrelado a isso: é o famoso DevOps. Então nós vamos explorar bem o que é o DevOps aqui. Eu costumo falar – em muito alto nível em uma palestra que eu faço – que todas as forças que a gente tem hoje, que fazer Software continuamente, colocar em produção o tempo todo, fazer muita experimentação, são forças de desestabilização e se você não tiver alguma coisa que te ajude a estabilizar, ou pelo menos a reagir rápido ao que está acontecendo no ar, isso vai ficar tudo no mundo das intenções. Então o DevOps é uma sigla que junta Desenvolvimento com Operações. E é algo muitas vezes confuso para algumas pessoas, por que significa tanto automação e ferramentas, quanto também significa cultura, enfim, é um tanto de coisa – e hoje em dia estão estendendo a sigla – então eu estou só dando uma passada geral para um tanto de coisa que a gente vai falar aqui. Então primeiro, para quem for corajoso, eu perguntaria: o que é DevOps?

M2: Então, essa definição do que é DevOps, pode parecer um pouco nebulosa, mas se a gente for pegar primeiro a definição da palavra, ela já começa a ajudar a gente a entender. DevOps quer dizer: a junção do time de desenvolvimento e do time de operações. E porquê que a união desses dois times é importante?

M1: Operação aí, é o famoso time da Infra.

M2: A famosa Infra, não é? Os meninos da Infra. Então, por que parece simplesmente que é a junção de dois times, mas quando a gente fala que o DevOps habilita o Agilismo, é porque as formas como as coisas funcionam antes do DevOps por natureza são lentas. Então vamos supor um processo tradicional: um desenvolvedor. Vai chegar uma história para ele, ele desenvolver a história, aí ele vai testar só na máquina dele. Que não necessariamente vai ser um ambiente similar, ou um ambiente produtivo, aquele time não vai ter autonomia de tomar uma série de decisões, e eles vão passar esse código para um time de QA – que as vezes fica até em outra localidade -, aí o time de QA vai fazer os testes dele, e as vezes não sabe direito o que realmente foi alterado internamente no código, não sabe claramente as mudanças de negócio que estão envolvidas. Então vão fazer aqueles testes e aí preparar um documento para requerer a mudança – os famosos RDM da vida – e passar por um posso de aprovação com um gerente – sim, estou falando aqui e olhando cara de vocês está até dando sono. Feito isso, esse gestor não sabe direito o que está entrando dependendo do perfil do gestor, tem um que só vai aprovar, outro que vai começar a fazer uma série de perguntas, marcar uma reunião para saber o que vai entrar nessa mudança, e isso vai passando tempo. Chegou para o time da Infra, o time da infra tem um SLA – por que chega um monte de coisa para eles – e dentro desse SLA vão fazendo a publicação (publiquei) [00:04:25]. Então o que essa morosidade está implicando? Está aplicando que fazer Deploy é um parto. Eu conheço várias pessoas trabalhando nesse modelo de trabalho, e que marcam na agenda o dia do Deploy, que vai se um dia estressante, que vai ter que virar a noite e “no dia seguinte vou ter que dormir mais porque teve deploy”.

M3: Não pode fazer na sexta.

M2: A gente está fazendo essa piadinha estressante, mas é muito comum no mundo da TI o pessoal ter Burnout, ter Depressão por causa de trabalho. E o processo que esses Deploy são realizados, são muito responsáveis por isso, responsáveis por horas extras. Então, narrei todo esse processo para a gente falar que, quando falamos de DevOps, envolve-se várias coisas, por isso é tão difícil conceituar ele e por que ele envolve também, a mudança de cultura.

M1: Só um comentário. A gente teve um episódio inteiro sobre LIM, e de cara a gente vê que o DevOps é para criar Flow. Por que hoje se tem um processo, que se você for pensar do ponto de vista de quem está puxando aquele fluxo de valor – que é o usuário que vai consumir aquele valor – até aquele valor ser gerado para ele é isso, via uma nova (inint) [00:05:42] por exemplo. Está falando que tem um processo cheio de desperdícios, e cheio de interrupção e feito por agentes que tem metas diferentes e interesses diferentes.

M2: É muito legal você trazer o LIM, eu vou falar um pouco – um pouco não, devo falar bastante – sobre o livro Accelerator. E ele coloca o LIM como um dos pilares do DevOps, mas quando eu for falar todos os pilares que eles enumeram e porquê enumeram, vai ficar um pouco mais claro.

M1: Então, você acha que no ponto de vista, não sei se só cultural, mas uma forma de enxergar o DevOps seria o seguinte: Eu sempre comento que o próprio Agilismoso – metodologia Ágil – ele poderia ser o NegDev, ela juntou o Negócio com o Desenvolvimento, em tese. Quando você pega lá no Extreme Program, e fala que você tem que ter o usuário dentro do time, você está tentando o aproximar, só que você cumpre só metade da tarefa. Quando você aproxima só o Desenvolvimento do Negócio, você ainda precisa aproximar a Operação também, para todo mundo se apropriar do fluxo e começar a gerar valor continuamente. Então um bom jeito de ver o DevOps – independente dos detalhes – é eliminar o desperdício e fazer o valor fluir o mais rápido possível. Vocês concordam com essa minha afirmativa?

M4: Concordo plenamente. E uma coisa interessante aí nesse parto que o Chagas narrou, é que a gente consegue identificar um monte de situações em que encontra alguns problemas. Na hora que você fala nesse fluxo de aprovação, e a passagem de bastão do time de Dev para um suposto time de QA e posteriormente um Workflow para o time de implantação. A gente tem que raciocinar o porquê isso foi criado, porque inventar precisa de todo esse passo a passo.

M2: Não foi à toa.

M4: Não foi à toa.

M2: “Nossa, vou tornar o processo moroso”, não foi isso.

M4: Exatamente. Então por que foi criado? Muito provavelmente por que a flexibilização – vamos colocar talvez no passado – ausência de ferramenta e de processo não vem ao caso – mas a flexibilização vinha a causar alguns problemas em produção, aplicação (inint) [00:07:57].

M2: Eu acho até que a gente pode falar, que a flexibilização irresponsável é muito perigosa.

M4: Irresponsável, muito bom. Então foi crido todo esse aparato, para garantir – estou colocando entre aspas aqui – que as publicações não quebrem o sistema. Pegando um gancho no episódio sobre LIM, se eu não me engano, isso é um Fix That Fail. É uma tentava de corrigir.

M1: Essa é a do pensamento sistêmico.

M4: Do pensamento sistêmico. Muito obrigado. É um Fix That Fail por que é uma tentativa de corrigir, que acaba causando um impacto negativo em toda situação.

M1: Sim, mas olha só que interessante, em um mundo de muita estabilidade, em que você queira atualizar pouco o sistema, talvez fizesse até mais sentido. Por que você fala assim: “Vou fazer poucos Deploys”, “quando fizer, não posso errar”. Tem um time que cuida da estabilidade e outro que cuida do desenvolvimento, é como se fossem duas missões bem distintas.

M2: E um atrapalha o outro nesse sentido, o time do Desenvolvimento está atrapalhando a estabilidade.

M1: Exatamente. Agora, no mundo em que você quer fazer atualizações nos ciclos mais curtos possíveis, até chegar em Lean e Kanban, dependendo da natureza do negócio, não dá mais para ter um time que só se preocupa com estabilidade e outro que só se preocupa em desestabilizar a estabilidade.

M4: E é engraçado, por que da mesma forma que o Tradicional (inint) [00:09:25] versus o Agilismo, veio uma evolução em que o mundo era mais estável, mais preditivo, e hoje em dia a gente fala que o mundo (inint) [00:09:37], é volátil. Então eu acho que o DevOps está tentando também corrigir essa mesma relação, lá no time operacional.

M1: É a contraparte ali.

M4: E é engraçado por esse que junto com esse Fix That Fail que eu comentei, vem também um problema de responsabilidade intrínseca – que é o que a gente comenta bastante -, quando você tem um time passando o bastão para o outro, um time não tem responsabilidade com o outro. Então o desenvolvedor vai desenvolver e não vai se preocupar tanto com a qualidade, por que o de QA vai fazer o QA se preocupando com a qualidade, mas talvez não se preocupando tanto com algumas informações que são importantes para o time de implantações implantar, não sei, parâmetros de base de dados. E aí fica aquela coisa, cada um cuidou do seu.

M1: E ninguém cuidou de todos, não é.

M4: Essa força desestabilizante que você sempre comenta, é um vetor forte ao longo desse fluxo e aí o que acontece no final das contas? Aquela velha relação abusiva, o time de operações, quanto menos eles implantarem melhor.

M1: Mas aí cumprem as metas deles.

M4: Se a meta do time é não desestabilizar? Quanto menos eu implanto, melhor.

M1: E sabe o que é mais curioso? Quanto mais o cara desenvolver e também não implantar, ele continua batendo a meta dele. Por que ele continua desenvolvendo, então se eles não implantarem não tem problema para ninguém. Você ia falar alguma coisa, não ia, Mateus?

M3: Então, é que eu acho interessante porquê a gente vem do meio de ideias, quase todo mundo aqui já desenvolveu em algum momento. E um livro que traz um prisma um pouco diferente – que é o prisma de quem é de operações – o Projeto Fênix do Gene Kim, quando eu li, foi uma coisa bem marcante, por que em um dado momento ele cita um exemplo de uma versão nova da aplicação que foi ser colocada em produções, e a conversa entre o time de operações era: “esses caras do desenvolvimento não sabem o que está acontecendo. Eles entregam esse código aqui, mas nem sabem se esse código vai rodar no servidor x ou no servidor y. Eles não sabem qual é necessidade de memória ou tipsador que aplicação tem”. Então a gente vê claramente essa diferença de interesses é péssima para tudo, por que a gente não vai conseguir um fluxo bacana, se a gente não conseguir atrelar valor se houver essas diferenças.

M1: Esse livro é interessante por que eu também sempre desenvolvi, e para quem desenvolve a Infra é dada. O cara fala assim: “Isso aí é, caixa preta”

M3: Caixa preta.

M1: E tudo que o lado de lá reclamar, falam: “lá vem aqueles caras enchendo saco de novo”, é impressionante a separação.

M2: Até essa cisão Brasil/Argentina que é criado com desenvolvedor Infra, é muito prejudicial. Por que você cria até um ambiente que chega a ser hostil, e isso só vai prejudicar os dois lados no final das contas.

M1: Então beleza, acho que já dá para ficar claro que a busca por ser LIM, juntar os times e colocar um objetivo comum. E você comentou Chagas, a questão do Accelerator, explica um pouquinho disso para a gente, o livro. E o que isso tem a ver com o DevOps para gente conseguir se aprofundar nesse tema?

M2: Em um livro recente, feito a partir de uma pesquisa, os autores fizeram uma pesquisa muito extensa – estou até com a minha colinha aqui – foram quatro anos de pesquisa, 23 mil entrevistados em 2 mil organizações.

M1: Você foi entrevistado ou não?

M2: Não fui entrevistado.

M1: Então eu não acredito nessa pesquisa.

M2: A própria abordagem deles, é uma abordagem científica a partir de uma pesquisa com um método. Eu costumo brincar que a gente fala, que tem Ciência da Computação quando a gente nunca trata a computação como uma Ciência, trata com improviso da computação ou vai no jeito da computação. Mas tem o aspecto cientifico, tem os aspectos de estar trabalhando com dados, fatos, hipóteses e teorias. Os autores desse livre começaram a trabalhar no DevOps com o aspecto científico então, a partir dessa pesquisa.

M1: Mas qual era a pergunta que eles queriam responder?

M2: Eles queriam identificar, quais eram os times mais performaticos. E aí, como eles mediram a performace desses times? Eles analisaram alguns indicadores – que são indicadores do Agilismo – então eles analisaram o Lead Time. O que é o Lead time? É o tempo desde que a área de negócio solicitou uma alteração (fithrua) [00:13:50], e isso foi colocado em produção. Então é um indicador clássico, quase todos True e Work ágeis para poder identificar a performace de Lead Time. Mas além do Lead Time, eles usaram outros indicadores também, como por exemplo: a frequência de Deploy. E a frequência de Deply pode parecer um indicador – em um primeiro momento – meio estranho, “Como assim? Porquê um time que faz mais Deploy é mais performático que o outro?”, mas ele é um dos indicadores mais importantes no sentido que ele está mostrando a capacidade daquele time, de conseguir lançar uma nova versão o quanto antes. E isso vai trazer uma série de vantagens por exemplo, inclusive de um dos outros indicadores que é o tempo até eu restaurar meu sistema de uma falha. O que é esse tempo, até eu restaurar meu tempo de uma falha? Houve um Bug em produção, mas consegui fazer uma nova versão corrigindo aquele Bug, – não estou fazendo Rollback não – e aí eu subi já aquela correção. Pode ser com o Rollback também, vamos fazer uma correção imediata aqui Acabei de fazer uma correção dum Bug da minha fala.

M4: Isso é interessante né Chagas, por que é o casamento de dois indicadores. Se você avaliar realmente soa estranho, talvez para quem está ouvindo e não está tão familiarizado, soa estranho. “Vou medir a quantidade de publicações que eu faço”, por que isso é relevante? Como você disse, por que isso mostra sua capacidade de reagir em situações de divergência.

M1: E interessante a definição de desempenho, para os caras, é um time que é capaz de gerar valor em curto prazo, continuamente, e se recuperar rápido quando estão com erro. É o que eu falo é bem apropriado ao momento que a gente vive.

M2: Sim. E todos os indicadores estão amarrados uns aos outros. Por que o Lead Time só vai considerar realmente concluída a história quando ela foi publicada em produção, e pera ela ter sido publicada em produção tem que ter um outro Deploy. E aí uma das coisas que pode gerar um medo, se eu gerar um monte de publicações?”, a porcentagem de publicação que vai ter falhas, vai ser maior, eu estou fazendo mais publicações, é algo matemático. Então o ultimo indicador deles é esse, a porcentagem de Deploys que vieram com falha. Porquê? Porque times performáticos – além de fazer muito Deploy -, a ideia é que o número de Deploys – entregas e produções com falhas – vá caindo ao longo do tempo. Então esse é ultimo indicador que eles mediram.

M1: São quatro basicamente, não é?

M2: São quatro.

M3: Mas é interessante observar também, que todos os indicadores – exceto o último – não tentam medir o quanto o time falha ou quanto o time deixa falhar. O último indicador serve para representar que índice de erros de Deploy, cai ao longo do tempo. Mas se o time tiver um tempo de resposta à falha rápido, Ok. Se ele consegue colocar uma versão nova da aplicação em produção rápido, a gente pode falhar, mas a gente falha rápido e recupera rápido.

M4: Fala rápido e recupera rápido.

M1: A gente recupera rápido.

M3: E o ambiente onde a gente vai aprender essa falha, também é um ambiente controlado. A gente não faz o teste, e um Releases de uma aplicação inteira em todos os usuários. A gente pode fazer Releases para um número menor de usuários são o Releases Canários – a gente pode falar mais sobre esses temas também -, mas a ideia é que o time seja rápido para colocar as coisas em produção.

M1: Rápido com cadência e sempre entregando resultado. Agora, o que isso tem a ver com o DevOps? Beleza, alguém olha para esse time e fala: “esse time é rápido”, e rápido em uma concepção moderna. Gera valor sempre para o negócio, ajuda a transformar o negócio. E o que o DevOps tem a ver com isso?

M2: Então, o time ser “rápido” a palavra é até ruim, por que “rápido” parece simplesmente que é uma questão de velocidade.

M4: De velocidade, não é?

M2: Mas por traz dessa velocidade, se escondem várias outras coisas, por exemplo: o próprio time ter autonomia. Então a gente entra na questão em que o DevOps, é muito mais do que simplesmente colocar uma esteira de produção, um Deploy Build Automatizado – a gente vai explicar um pouquinho depois o que é Deploy Build Automatizado -. Então nesse mesmo livro, Accelerator, eles identificaram várias características que são comuns aos times que são performáticos, que têm aqueles quatro indicadores na alta. E eles dividiram-na verdade identificaram – 24 características com correlação, times que têm um bom desempenho também tem essa característica. Então utilizando a correlação, eles dividiram essas 24 características em um grupo de cinco temas principais, e um desses temas é a Entrega Continua, mas normalmente as pessoas reduzem todos os temas a somente esse tema da Entrega Continua, e não é só a ela. Além da entrega continua tem os aspectos da Arquitetura – voltando e explicar um pouco do porquê a Arquitetura está fora da Entrega Continua – às vezes parecem coisas que estão ali – está o Meneger LIM – então gestão LIM é um dos fatores também. A questão da cultura entra muito na diversidade das equipes, nessa questão de cuidar da saúde dos times, evitar o Barnaut, etc. E o quinto tema é Produto e Processo, que a gente precisa mexer as vezes em como os processos das empresas são feitos para você habilitar todos os outros temas do DevOps.

M1: Então, só para ver se eu consigo clarear, para quem está escutando. A gente está falando sobre DevOps, e aí fomos falar que existe um estudo que tentou responder o que torna – primeiro – o que indica que tem um grande desempenho e aí foram encontrados cinco temas principais.

M2: Exatamente.

M1: Desses cinco temas, o Entrega Continua é a mesma coisa que DevOps? Tem a sobreposição de alguns temas? O que é o DevOps nessa brincadeira?

M2: Uma Entrega Continua é uma parte do DevOps. Então vamos explicar primeiro o que é Entrega Continua, que normalmente é o que é DevOps simplificado.

M1: O pessoal enxerga mais materializada – vamos dizer assim.

M2: Exatamente. É eu entregar o Software de forma automatizada, impactando diretamente o número de Deploys que eu consigo fazer. Então, para entregar Software, basicamente tenho que fazer algumas atividades. Qual é a primeira? É o Build, um Software de código, mas código não é o que é executado nas maquinas, o que é executado são programas. Então o processo de Build é o processo de converter esse código em um programa, e aí existem vários outros fatores que estão ali dentro, etc. Depois que eu faço esse Build, tenho que subir isso para o servidor, (isso é) [00:20:54] o Deploy. Então o processo de entrega continua envolvendo a automatização Build e a automatização do Deploy, mas não só isso. Por quê? Se eu não tiver confiança no meu sistema, eu não posso ficar fazendo Deploy de qualquer coisa, o Desenvolvedor desenvolveu ali e pode ter uma falha crítica. Então tem todo um ecossistema que habilita e executa isso de forma segura. Em um dos episódios passados, a gente falou sobre os Testes Automatizados. Teste Automatizado é um dos drives que habilita a Entrega Continua – por que eu vou ter confiança no meu sistema – e ele está seguindo uma série de regras descritas nos testes – eu posso colocar isso no meu Pipeline, na minha Esteira Automatizada. Então eu fiz o Build e rodei os testes, se os testes falharam, eu não vou fazer um Deploy de uma coisa que deu alguma falha no teste e então você já volta. E isso é muito rápido, diminui o ciclo até eu descobrir o erro.

M1: Então a gente pode dizer – sem querer ser pessimista demais – que o DevOps é tanto aquela aproximação dos times – que a gente comentou anteriormente – para que eles trabalhem juntos em prol do mesmo objetivo. Mas no exemplo que você deu, sustentados por ferramentas que permitem automatizar os processos que (vou fazer) [00:22:07] ficar efetivamente eficiente. No caso, Build automático, Suítes e Teste Automatizado.

M2: São testes por exemplo: de segurança. O pessoal gosta de ficar inserindo sigla dentro de sigla, fala-se de DevSecOps, mas além de teste de segurança, a gente pode ter também testes de cargas, embutido nisso. Além de todos esses testes, a gente tem a questão de dar autonomia para os times. E como a gente habilita essa autonomia, sem estar sendo responsável? Como você falou no início – sobre a questão da responsabilidade – a gente tem que criar um ecossistema que os times vão conseguir experimentar, e aí já entra em do outro pilar, que é a questão da Arquitetura. Eu tenho que ter Arquiteturas que vão facilitar esse processo, por exemplo: trabalhar com container. Por quê que trabalhar com container facilita esse processo? Cada time vai conseguir reproduzir um ambiente produtivo na sua máquina, cada time vai conseguir trabalhar com uma linguagem diferente, por que eu posso ter Containers com linguagens diferentes. Então eu dou autonomia para o time escolher a linguagem que vai melhor atender aquele problema em questão. E quando a gente fala disso no ambiente corporativo, em um primeiro momento assusta, “não vou trabalhar com um (Steck) [00:23:18] múltiplo de linguagens, já tenho essa curadoria aqui”. Por exemplo, essa echarpe, não vou inserir um Python aqui que vai me trazer muito risco, não sei trabalhar com Python, repositório Python, como é isso? Eu já tenho o meu Nuguete, o que é o nuguete? Minha biblioteca de componentes aqui da empresa, controlada, inserir uma nova tecnologia vai inserir uma série de riscos. De fato, vai, isso é verdade. Mas eu dar autonomia para o time escolher uma tecnologia que vai entender aquele problema, traz tantas vantagens que vale a pena você criar um ecossistema, que minimiza esses riscos, eles ainda vão existir, mas minimizados. Então, o aspecto de Arquitetura trabalha por exemplo com Micro Serviços, que não é uma bala de prata – é sempre bom colocar isso aqui – mas não precisa necessariamente ter com Micro Serviços, eu posso ter monolitos conteinerizados e isso vai dar liberdade para o time trabalhar com as tecnologias ali. Então isso já abrange o outro aspecto, que é o aspecto da arquitetura.

M1: O que é um Container? Supondo que alguém não esteja entendendo o que é um Container.

M2: Você quer explicar?

M4: Container é uma abstração de uma máquina virtual.

M1: Por que não é uma máquina virtual?

M4: Vou pegar no passado. A gente utilizava o que chamávamos de (Berry Metal) [00:24:39], que são as máquinas de fato rodando em um datacenter, e toda publicação feita naquela maquina Windows ou Linux, que você conhecia até o nome da máquina. Depois fomos para um ambiente virtualizado, onde você utilizada uma única máquina, mas implantava lá em um VMware da vida, uma outra máquina também Linux, com Windows virtualizada. Já reduziu bastante o tempo em que se necessitava subir um ambiente, mas ainda assim, tem uma certa morosidade, demora ali minutos ou dependendo do time de Infra, demora até horas para subir um ambiente. O Container é uma abstração – vamos dizer assim – sucinta, uma abstração compacta de uma máquina virtual, porque ele é um Microkernel, e normalmente ele não tem todo um sistema operacional, ele sobe só o que é necessário.

M1: O mínimo necessário para rodar.

M4: O mínimo necessário para aquela aplicação. É como se você pegasse um Container – desses que andam em navio -, e jogasse lá dentro só o que você precisa de fato para rodar sua aplicação. Assim, é possível colocar um Container no ar em milissegundos. Toda essa questão que o Chagas está comentando é habilitada pela utilização de um ambiente que chamamos de conteinerizados.

M2: E tudo isso para a gente ter um Deploy mais tranquilo, não aquele Deploy tenebroso que eu fui narrando no início. Normalmente as pessoas usam muito a figura de um foguete decolando para poder ilustrar o Deploy, e eu acho que essa é uma figura errada.

M4: Uma metáfora ruim.

M2: Uma metáfora ruim, exatamente. Por que o lançamento de um foguete não é uma coisa frequente, é uma coisa demorada, planejada, complexa, e que evolve milhares de times. Existe uma outra metáfora, que é um pouco mais aderente ao Deploy que a gente deseja ter, talvez os foguetes sejam os Deploys que temos atualmente em vários cenários, mas quais são os Deploys que a gente quer ter? O interruptor, que é a outra metáfora mostrada as vezes. O interruptor para acender a luz. Uma pessoa vai lá e aperta um botão, e se quiser desligar, ela vai lá e aperta o mesmo botão. Acender a luz é algo muito mais comum, todos os dias a gente apaga e acende milhares de vezes. Mas lançar foguete é uma coisa mais rara – eu pelo menos nunca lancei um.

M1: Uma pergunta que me vem à cabeça, é que sempre o DevOps é muito associado a arquiteturas na nuvem com essa questão de Containers. É verdade isso?

M2: Arquitetura na nuvem facilita sim a execução do DevOps, porém, ter uma arquitetura interna – ou até uma nuvem privada – não quer dizer que vai ser impossível implementar o DevOps. As ferramentas – falando agora – por exemplo do aspecto de bi automatizado para o automatizado, e vamos dar os nomes para as ferramentas. As vezes o pessoal escuta “Jenkins” “DevOps” que são as mais famosas, tem o Trevs para (inint) [00:27:42]. Então, essas ferramentas trabalham muito bem com sistemas internos, fazer uma publicação no meu servidor local, e o grau de dificuldade de fazer isso, é só um pouquinho a mais – digamos assim -. As vezes a nuvem já tenha as coisas prontas ali, mas para configurar, para o funcional em um ambiente local é possível.

M1: Então alguém não pode supor: “Só na nuvem eu faço um DevOps”.

M2: Isso, eu ia falar exatamente isso. Essa pergunta é muito boa, porque as vezes existem desculpas dadas como: “Não, não vou implementar esse negócio de DevOps aqui, eu tenho meus próprios servidores”, enfim, isso aí não cola.

M4: E interessante é que se a gente analisar – até pelo que você já comentou do Accelerator, e dos cinco pilares – você tem uma infraestrutura na nuvem, ou uma infraestrutura On Premisse, vai atuar em um desses pilares que é a parte de Deploy Automatizado. Todos os outros, aspectos culturais, enfim, não importa muito onde.

M1: Mas não ficou muito claro para mim. Esses aspectos culturais, a mudança de processo, visão politizada – que vos comentaram – está dentro dessa disciplina do DevOps? Ou não? Entendeu?

M2: Está dentro. Vamos pegar o exemplo que é mais fácil de visualizar isso – mas existem outros -, quando gente fala em autonomia do time, é necessário para que o DevOps execute. Então para que eu tenha muitos Deploys, meu time vai ter que conseguir fazer várias etapas de forma autônoma. A gente não está dizendo que vai tirar processo de autorização de Deploy, por que esse é importante para auditoria, e importante por uma série de motivos. A gente está querendo dizer que o vai desburocratizar a maior parte das etapas. Para o time ter autonomia, tem que ter uma mudança de cultura, tem que ter uma confiança no time. E aí, quando eu estou falando do time, eu estou (corroborando) [00:29:33] desenvolvedores – pensando no time de Scrum, que não é só um time de desenvolvedores, é um time multidisciplinar. Precisamos acreditar que esse time está fazendo um bom trabalho, e as vezes essa crença de que ele tem que envolver uma mudança cultural, para que toda companhia tenha essa confiança de dizer: “essa parte aí está fazendo a entrega”.

M4: A gente fala muito em Squad. A mudança do tema de time para Squad, envolve toda uma cultura em torno daquilo. Talvez o DevOps seja a implementação do time de Squad, ou talvez ele seja um processo.

M2: Uma transformação de times em Squads.

M1: Por que o Squad tem realmente que se apropriar do fluxo. Isso é outra pergunta que eu quero fazer. Muda bastante o perfil da pessoa de Infra, por que está ficando tudo mais Software, ou seja, – o Felipão falou – antes o cara enxergava uma computador e ficava mexendo no computador. Agora, em muitos casos está até aprendendo a disparar um Container.

M4: Eu acho que realmente isso altera muito.

M1: Como é, esses caras estão indo todos trabalhar na Agere e na WS?

M4: Eu não diria trabalhar na Agere ou na WS, mas pelo menos com a Agere e com a WS, sem dúvida. Ou, acho que eles vão ficar fadados ao nicho, porque no de sustentação do que ainda sobrar de soluções.

M1: Mas tem cada vez menos gente entendo de Hardware mesmo. A gente vai ficando cada vez mais isolado do Hardware.

M4: Se você pensar – e agente já até falou isso em um outro episódio – que o Algilismos prega maximizar o esforço naquilo que vai gerar valor, aí a gente vai se perguntar: realmente vou ficar me preocupando quantos pentes de memória se tem na máquina? Se é HD? Então isso aí, (inint) [00:31:18].

M1: Mas a tecnologia hoje, nos permite disso.

M4: Exatamente.

M3: Mas eu acho que um outro elemento do DevOps que tem feito essa mudança do perfil do profissional de infra, é que o código também chegou na infra. E hoje em dia você consegue descrever seu ambiente como um código. Então você não depende mais de o fulano saber que aquele servidor está rodando o IP tal, ele tem tanto de memória. Você tem código que descreve isso.

M1: Infra is a code.

M3: Infra is a Software, não é?

M2: Infra is a code. Você pode até se preocupar com o pente de memória, mas você tem código que descreve isso. Você vai executar esse código, e ele vai estar implementando (inint) [00:31:58].

M4: Até para não estimular a ira dos profissionais de infra que possam estar nos escutando. Não é que isso se torne algo desimportante, mas isso passa a ser uma variável, mais um parâmetro de um outro mundo infindável de parâmetros, que você tem manter no seu ecossistema produtivo. Então a infra, passa a ser um parâmetro controlado por esse time autônomo e multidisciplinar.

M1: E essa disciplina do DevOps, como se dissemina dentro do Squad? Tem alguém que cuida disso? É uma competência distribuída pelo time? Não existe um modelo tão fixo? Qual é a sua visão?

M2: Tem a resposta da literatura, e o que a gente vê na prática. A resposta da literatura diz que todos do time têm que ter o Skill necessário para poder fazer essa implementação. Mas, o que a gente vê acontecendo as vezes, é a centralização de um perfil DevOps. Existem até algumas empresas que têm cargo de Engenheiro DevOps, um cara que vai estar especializado nisso. A gente entende que talvez seja até um processo de transição do mercado, que realmente tenha que ter esses profissionais nesse primeiro momento, para eu conseguir fazer essa transição, por que envolve estudos de uma série de ferramentas. Envolve estar de fato forçando essa mudança de cultura – que não é algo tão simples – mas, vislumbrando a longo prazo, o ideal é que todo time tivesse a capacidade de executar as tarefas envolvendo o DevOps. Até porquê, a ideia é simplificar o processo e que aquilo seja o menos invasivo possível, para a gente sempre aumentar nosso foco, que é aumentar o número de Deploys.

M1: Beleza. Tem mais algum aspecto que vocês queiram comentar?

M4: Uma coisa que o Mateus citou aqui – e eu acho interessante – foi que essa cultura de DevOps desde a esteira de publicação automatizada até a mudança cultural – e como a gente gosta muito de costurar a linha em relação aos outros episódios, é o Agilismo em si – se a gente fica repetindo, que ser ágil, gerar valor continuamente, construir hipóteses, testar essas hipóteses, falhar rápido e aprender rápido, eu acho que o DevOps é um grande aliado nesse desafio. E ele traz alguns ferramentais que habilitam – como o Mateus comentou: testes canário, testes AB – que são possibilidades de você avaliar pequenas alterações no seu produto, e perceber que se alguma dessas alterações causou o impacto positivo ou negativo, você conseguir reagir rápido a essas percepções. Então só para conceituar o Teste Canário, é você colocar uma novidade, uma nova (inint) [00:34:59] em produção, mas não habilitar aquela (inint) [00:35:03] para todo o público, para toda sua base de usuários. Você coloca dez a 20% da base de usuário, ver como aquela novidade vai se comportar. Até porquê – pegando um gancho no episódio de automatizados – o Kent Back falava muito que estatisticamente é impossível você ter um sistema livre de Bugs, então eles vão acontecer. Mas se você tiver em uma publicação Canário, aqueles Bugs vão afetar dez a 20% do seu público. Então você não vai ter um dano catastrófico. E até fazendo um parênteses aqui, explicando o porquê desse termo “Publicação Canário”, ou “Testes Canários”: ele vem da época dos mineiros – das minas de minério mesmo, não os de Minas Gerais – principalmente de minas subterrâneas, onde em determinado momento o nível de oxigênio podia abaixar muito, então eles colocavam um canário eu sei que é cruel – acredito que hoje em dia isso não seja feito mais, e o teste Canário em Software não utiliza um canário.

M3: Tem certeza?

M2: Nenhum canário sofreu danos nesse processo.

M4: Mas o fato é que o canário morria primeiro, e os mineiros tinham a chance de evacuar a área. Então é obviamente uma metáfora utilizada atualmente, mas que é a mesma lógica. Se o sistema falha para 10%, você ter uma base menor de usuários que vão morrer com aquela publicação, e não vai causar nenhum impacto na sua população inteira. E os testes AB? Que é quando a agente quer fazer algum teste, a gente tem uma hipótese, mas não sabe se a forma A, ou a forma B é melhor para atender o usuário.

M2: Acho que gente pode até usar um exemplo concreto: eu tenho um botão na esquerda e outro na direita, mas eu não se vai ser na esquerda ou na direita que o usuário vai ver, e clicar mais nesse botão.

M4: Exatamente. Então você faz duas versões, uma com botão na direita, uma com botão na esquerda – obviamente aliado a um conjunto de ferramentas de monitoramento, de gestão da aplicação em produção. E após analisar essas métricas, você vai ter uma noção melhor de si para aquela base de usuário – o botão funciona melhor na direita ou na esquerda? – e você simplesmente mudar o interruptor e levar todo seu público para aquela versão mais adequada.

M1: (inint) [00:37:21] mais científico, não é?

M4: Exatamente.

M2: Inclusive uma palavra muito importante que o Felipão trouxe: é monitoramento. Ele é uma daquelas 24 Skills que é importante de ter. Monitoramento é uma delas, por que não adianta nada a gente estar fazendo esse tanto de teste, se a gente fica no escuro. Então faz parte do DevOps ter um sistema de monitoramento bom. E quando a gente fala de monitoramento é tanto, digamos, de infra – ao consumo de memória a chamadas com erro – quanto (Log) (inint) [00:37:51] de Negócios mesmo, mapa de calor de site, utilização de (inint) [00:37:57], etc.

M3: Voltando no episódio de teste, que a gente falou sobre a (inint) [00:38:02], essa rede de segurança. A gente falou que o teste constrói uma rede de segurança para o Software, se executado. O DevOps amplia essa rede, então a gente pensa – e realmente quando se pensa – em Deploy Continuo. Talvez o Deploy continuo seja uma segunda etapa dessa rede de segurança. Você vai criar uma cultura, vai criar um ambiente, usar algumas ferramentas que criam essa rede de segurança, então se você pensar em um artista de circo que sempre anda em uma corda bamba, sempre tem uma rede em baixo dele. O DevOps talvez seja essa rede que fica em baixo do artista. Então a gente vai criar essa rede, e à medida que formos tendo mais confiança, os Deploys que a gente fizer vão ficando em uma frequência maior, eles vão funcionando melhor. Talvez apareça mais, talvez a gente vincule mais ao Deploy continuo, por que o Deploy antigo é realmente uma ferramenta, uma forma muito interessante de se gerar valor. Mas você não vai conseguir fazer isso se você não tiver um ambiente que possibilite que isso aconteça, que garanta que isso possa acontecer. Essa rede de confiança e segurança é fundamental.

M2: Uma coisa que eu acho muito legal de trazer aqui também, é que a primeiro momento pode parecer que esse trem de DevOps é para empresas como: Spotify, Netflix, empresas que já nasceram digitais, ou StatUps, uma empresa menor que não tenha preocupações com a consequência tão grandes de um Deploy errado. Mas ele é completamente aderente a negócios tradicionais, ao banco. Por exemplo no livro Accelerator, ele traz um Case de transformação digital, e que vem através implantação do DevOps em um banco tradicional, com todo o desenvolvimento anterior seguindo cascata, totalmente profissional. Então, aplicação do DevOps não é exclusividade de empresas pequenas, ou empresas que já nasceram digitais ou cases como Spotify e Netflix. Ela é uma possibilidade inclusive, para negócios tradicionais, obvio que implementar isso vai passar por vários processos. Vai ter até uma fase de transição, em que você vai implementando partes até chegar (inint) [00:40:21] final do DevOps, digamos. Mas é possível então que as vezes o negócio ou o cliente, possam ficar com uma certa resistência pensando: “não, isso aqui é tão aderente ao processo”.

M4: “Muito legal, mas não serve para mim”.

M2: Nossa, eu queria muito ter isso – não é assim tão simples – mas é possível.

M1: Mas eu diria que nem há possibilidade, vai ser cada vez mais um hiperativo. Caminhando para o final, o que eu acho curioso como um círculo que se realimenta, de alguma forma, a gente precisa entregar Software mais rápido, e começaram a surgir coisas que viabilizam entregar Software mais rápido. E aí alguém começou a usar isso, levantar a barra muito, então ninguém consegue escapar mais disso, e eu acho isso é um ponto muito importante. Agora, acho curioso que se você pega tanto o Ágil quanto o DevOps, no fundo são manifestações de algo que é para fazer o fluxo ficar mais eficiente, e você se concentrar na geração de valores. É muito LIM isso mesmo, eles parecer até que são temas transitórios, que daqui há 30 anos não se vai mais precisar falar sobre isso.

M3: Não vai mais precisar falar sobre o DevOps.

M1: Eu vou falar assim: “Como assim DevOps?” É claro que a gente desenvolve da Deploy.

M2: “Existia alguma coisa antes disso?”.

M1: “Como assim eu desenvolvia sem conversar com o usuário? Como assim?”.

M3: “Como você fazia um código que não tinha teste?”.

M1: Parece como se fosse um momento de transição.

M2: É que parece óbvio, não é? Quando você para pensar, não tem jeito de fazer assim.

M1: Eu faço Software assim, o cara está do meu lado e a gente toma decisão juntos e ainda faz os experimentos. Talvez vá ter um novo troço aí, por que a gente sempre acha que está avançado, até surgir a nova onda. Mas é isso, a gente pretende fazer ainda alguns episódios com esses conceitos mais técnicos, inclusive se tivermos o feedback de dúvidas, de coisas que vocês ouviram e pareceu um pouco misterioso, a gente gostaria muito de poder esclarecer. Talvez abordar mais Arquiteturas, falar mais sobre microsserviços, que são todos temas dos quais a gente não pode fugir mais. Um abraço a todos.

M2: Abraço, galera.

M3: Valeu, pessoal, um abraço.

M4: Valeu, pessoal, até a próxima.