First of all, it’s all about Agile!

A metodologia DevOps foi criada utilizando os conceitos dos métodos Ágeis, para entregar um grande valor durante o processo de desenvolvimento de software, automatizando o release de features compipelines, para conseguir provar hipóteses mais rápido e assim se adaptar mais rápido às mudanças por meio de uma abordagem “fail-fast”. Essas mudanças são mais culturais do que técnicas, portanto é comum dizer que DevOps é cultura.

A implementação de DevOps acontece por meio da automação de processos, tendo muito forte dentro dessa implementação a reengenharia de processos da empresa. A implementação da parte técnica é simples e fácil se comparada com a mudança de comportamento das pessoas. Portanto, é bastante confuso o papel que um “Engenheiro/Analista DevOps” desempenharia, no meio dessa confusão, existem muitos SysAdmins e Analistas de Infra assumindo o papel de “DevOps”.

First things first, Lean é a base do Agile

A realidade não é tão feliz quanto parece. Depois da segunda guerra mundial, o Japão estava destruído e com poucos recursos, após ter perdido a guerra. Com uma quantia limitada de recursos, o país precisou se reinventar e sobreviver após uma época de forte depressão, durante essa época dois caras ficaram famosos pelo trabalho realizado dentro de uma empresa, que mais tarde teve o nome dedicado ao modelo que foi criado.

Esses caras eram Eiji Toyoda e Taiichi Ohno, que trabalhavam para a Toyota Motor Corporation. Foram os fundadores do modelo de produção Toyota, também conhecido como Toyotismo.

Toyota deu origem ao Lean

Lean é uma metodologia que ensina a otimizar os processos da empresa; end-to-end, para dar mais atenção às tarefas que entregam valor ao consumidor final, incentivando ao máximo a remoção de bottlenecks no processo, assim como a análise de tarefas que são desperdício (definidas pelos 3M) para que sejam identificadas e removidas.

Essas tarefas consideradas desperdício são classificadas como 3M dentro do Lean que representam: Muda, Mura, e Muri. Outro ponto importante a destacar no processo é a utilização do método nomeado Kaizen (continuous improvement), com foco em melhorar continuamente buscando atingir um nível de excelência em qualidade.

A qualidade faz parte da cultura japonesa, pois existe a crença de que um produto de qualidade traz o cliente de volta, mesmo que os produtos demorem mais para estragar, os clientes serão fiéis a eles, pois terão uma boa experiência. Antes mesmo de falarmos sobre user experience, eles já estavam pensando nisso.

Kaizen

Um mindset que ajuda a olhar para cada parte do processo exclusivamente e pensar nas melhorias, envolvendo as pessoas que fazem parte do processo, assim incentiva que haja a inclusão dessas pessoas nas decisões de mudança, já que:

• Fica muito mais fácil de aceitar uma mudança quando ela não é imposta (top-down);
• Há uma absorção maior das mudanças pelas pessoas, quando elas são incluídas no processo;
• As pessoas que são incluídas no processo trazem as suas preocupações e sugestões, que contribuem positivamente com a evolução da mudança, tornando a ideia mais robusta.

O processo de definição das melhorias por meio de Kaizen acontece (normalmente) na seguinte ordem:

1. Definir objetivos com base em dados;
2. Revisar o estado atual e desenvolver um plano de melhoria;
3. Implementar a melhoria;
4. Revisar a implementação e corrigir o que não funciona;
5. Reportar os resultados e determinar os itens a serem monitorados.

Esse processo é bastante chamado de PDCA: Plain-Do-Control-Act, que se resume em:

• Plan (desenvolver a hipótese);
• Do (executar um experimento);
• Check (validar os resultados);
• Act (refinar o experimento e recomeçar).

3M: Muda, Mura, Muri

Muda (desperdício)

Qualquer atividade que consuma tempo sem agregar valor ao consumidor final. Como por exemplo:

• produção em excesso;
• tempo parado (ocioso) no processo;
• defeito nos produtos.

É importante lembrar que existem níveis diferentes de Muda que podem ser ou não removidos com rapidez, e a classificação depende do tempo para remoção.

Um exemplo de Muda mais demorado é a descontinuação de um software legado que acaba tendo ciclos mais longos de release, causando tempo ocioso nos times, muitas vezes uma rotina de testes longa e manual.

Mura (desigualdade)

Atividades que são muito variáveis e imprevisíveis, gerando resultados diferentes em todas as execuções. Por exemplo: a execução de tarefas que não foram bem planejadas e acabam chegando com prazos rígidos. São executadas na correria, gerando um desgaste, desespero, e ainda por cima, ao terminar deixam as pessoas que executaram essas tarefas esperando (seja um feedback, ou então a confirmação de que está finalizado).

Muri (sobrecarga)

Exigir que as pessoas (ou os equipamentos) trabalhem além do limite, para atingir algum tipo de meta ou expectativa, gerando cansaço e consequentemente falhas durante o processo. Essas falhas são geralmente erros humanos causados pelo cansaço durante o trabalho excessivo.

Voltando ao Agile…

No ano 2000 um grupo de 17 pessoas se encontrou em um resort em Oregon para conversar sobre ideias que poderiam melhorar o fluxo de desenvolvimento de software. Depois de um ano de amadurecimento das ideias, essas pessoas se encontraram de novo e publicaram as ideias, que hoje conhecemos como: Agile Manifesto.

Os principais pontos são:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Vou me restringuir a explicação desses pontos com o ponto de vista DevOps, para não fugir (mais) do tema.

Individuals and interactions

over processes and tools

As pessoas devem receber o kit de ferramentas (tooling) apropriado para trabalhar e então serem empoderados para realizar seu trabalho. As interações entre pessoas é extremamente incentivada, para o compartilhamento de conhecimento e também para facilitar o fluxo criativo dentro dos times de desenvolvimento.

Um excelente exemplo de interação incentivada por meio de DevOps é o hábito de code review. Considerando que pequenas partes do software serão iteradas e aprovadas no pipeline passando por diferentes ambientes, de maneira automática, o melhor jeito de prevenir defeitos é por meio de code review.

Esse hábito traz benefício como:

• Compartilhamento de conhecimento no time;
• Observação do problema em diferentes pontos de vista;
• Engajamento no time;
• Redução no número de bugs.

Working software

over comprehensive documentation

Aqui existe um trick na questão do working software, um software que funciona não é “compilou, tá funcionando”. O software que funciona é o que atende aos requisitos do usuário; i.e. o software que resolve o problema e as dores do usuário.

Como o mercado é muito dinâmico, e evolui com grande velocidade, muitas vezes durante o projeto de desenvolvimento de software os requisitos mudam devido a fatores externos. Portanto, sabendo que não é possível prever todos os fatores, muitas gambiarras são feitas no meio do caminho e documentadas, para que o usuário final aprenda a lidar com as falhas, e executar os workarounds, gastando mais esforço do que seria necessário para realizar as tarefas por meio do software.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo

Incentivando assim que hajam deployments tanto quanto o possível, para que as falhas aconteçam o mais cedo possível, permitindo assim que o impacto delas seja bem menor.

Fail-fast!

As falhas são compreendidas e incentivadas, pois faz parte do mindset entender que:

• Só erra quem faz;
• Falhas acontecem.

Portanto é melhor que as falhas ocorram cedo, enquanto o custo de correção ainda é baixo. Falhar em um ambiente controlado de testes, permite que a correção seja muito mais rápida (e barata) do que seria caso a correção acontecesse já em produção.

Para que essa abordagem tenha sucesso, existe a premissa de que os ambientes sejam cópias de produção, ou pelo menos que seja o mais próximo possível. Do contrário, haverão mudanças de comportamento no software entre os ambientes, inviabilizando o ambiente de testes.

Caso os ambientes sejam divergentes, a promoção de bugs para produção será muito frequente, causando falhas tarde, que são falhas caras.

Customer collaboration

over contract negotiation

Também é possível que haja um má levantamento de requisitos durante o início do projeto, pois muitas vezes o próprio cliente/usuário não conseguiu prever todas as funcionalidades necessárias.

Podemos descrever essa situação como:

• Do ponto A é possível ver apenas o ponto B;
• Do ponto B é possível ver o ponto C;

Portanto há um grande incentivo para que o software seja entregue em partes, continuamente. Colhendo assim os feedbacks do usuário sobre os próximos passos, seguindo os conceitos de prototipação evolutiva, que foram muito divulgados por meio do livro The Lean Startup.

Esse ponto faz muito contraste com o anterior, em relação à entrega contínua (continuous release), para que seja possível apresentar o protótipo e evoluir ele ao longo do projeto.

Saiba quem é o seu cliente/consumidor/usuário, e para quem você está fazendo o software, pois esse é o único jeito de conseguir entregar valor para esse cliente. Parte importante do processo de desenvolvimento de software é ser empático com os problemas do usuário, e entender de verdade qual é o problema a ser resolvido, e o resultado causado pelo impacto no desenvolvimento do software (geração do valor para o usuário).

Responding to change

over following a plan

Fazer um redesign dos requisitos durante o projeto é parte crucial para o sucesso do projeto. Será o único jeito de conseguir trazer para a mesa todos os problemas do usuário, e criar a melhor solução para todos esses problemas, pois só o usuário sabe dos reais problemas que ele enfrenta no dia-a-dia lidando com o software.

Com a entrega contínua de software junto com o monitoramento dos resultados, o processo de coleta dos feedbacks fica muito mais simples e rápido.

DevOps, DevOps, DevOps

Com a divulgação da palavra DevOps, existe muita gente falando sobre DevOps por aí. Existindo muita divergência no que é falado, e criando uma confusão grande sobre o tema. Acaba sendo muito comum se deparar com diferentes interpretações sobre o que é DevOps. Existe muito eufemismo na área, e gourmetização em cima do LinkedIn, com muitos SysAdmins por aí se dizendo DevOps, pois aprenderam a codar shell script dentro do Python.

Os benefícios da implementação de DevOps

Principais benefícios que uma companhia geralmente espera e encontra na adoção da cultura:

Releases mais rápidos e baratos

Como os releases serão frequentes, as entregas acabam sendo pequenas. Entregas pequenas trazem o benefício de aumentar a velocidade no ciclo de desenvolvimento (entregando sempre)

Suporte operacional melhorado com ajustes rápidos

Caso haja alguma falha durante a entrega, o impacto é menor pois a quantidade de modificações é pequena, assim como o rollback é rápido.

Melhor time to market (TTM)

O software será entregue muito mais cedo, quando ainda for um MVP. Os clientes serão integrados como parte do processo de desenvolvimento, trazendo insights e feedbacks para o time. Permitindo assim que haja uma velocidade maior de lançamento no mercado.

Produtos de qualidade superior

Como foi falado antes, falhar cedo impede que defeitos sejam entregues em produção

Assim como:

• Menor volume de defeitos no produto como um todo;
• Aumento na frequência de novas features e releases;
• Processos de desenvolvimento apropriados nos times, incluindo automação.

Agora que entendemos o POR QUE, vamos ao COMO

Continuous releases (integration, delivery, deployment)

Geralmente segue uma abordagem de versionamento de código (por meio do Git) utilizando branches específicas para cada ambiente.

Continuous integration

Execução automática dos testes unitários, integrados e também de qualidade de código na branch, para garantir que não houve quebra de funcionamento do pedaço modificado do código.

Continuous delivery

Empacotamento do software que está testado e aprovado, para deixar ele em algum lugar que seja possível fazer um deploy posteriormente. Exemplos são libs entregues em repositórios para ser integradas no código durante o próximo update e deploy de código

Continuous deployment

Após conseguir completar todos os passos anteriores, é possível fazer deploy automatizado direto nos ambientes, quando o time estiver com mais confiança em relação às ferramentas que testam, assim como com a questão de assumir riscos e entender que existe a possibilidade de falhar em ambientes de teste, sem preocupações.

Configuration (e/ou Infrastructure) as code

Para que seja possível testar o software com assertividade, e entender que ele irá transitar entre os ambientes sem mudar de comportamento, é de extrema importância que as configurações sejam também código. Isso permite que as configurações sejam também versionadas, acompanhando o código. Garantindo também uma uniformidade entre os ambientes, que possibilita:

• Redução nos custos de manutenção, tendo um ponto único para olhar e entender o funcionamento do sistema;
• Facilidade para recriar a infraestrutura, caso seja necessário mover tudo para outro lugar, isso pode acontecer com poucas interações manuais;
• Permite que haja code review da infraestrutura e das configurações, que por consequência traz uma cultura de colaboração no desenvolvimento, compartilhamento do conhecimento e aumenta a democratização da infra;
• Documentação como código, ajudando novos membros do time a terem um warm up mais rápido.

Esses pontos foram bem estressados pelo time da Heroku, e deram origem ao famoso paper: The Twelve-Factor App. Uma leitura muito boa para a explicação dos benefícios sobre gerência de configuração.

Monitoramento e self-healing

Ao fim de todo o processo de entrega, o software deverá estar sendo monitorado, para que não seja necessário esperar um report externo de falhas, garantindo que as ações sejam pró-ativas e não reativas.

Garantir que o monitoramento esteja maduro, também nos permite automatizar a parte de reação aos alertas, criando um sistema de self-healing em que ações (scripts) são executados para corrigir possíveis falhas conhecidas na infraestrutura. Permitindo assim que todos possam dormir tranquilamente de noite, sem ter que ficar preocupado com o plantão tocar e ter que ler documentação de madrugada. (Se você já teve experiência com isso, sabe com certeza o quanto é ruim).

Escalando assim apenas os casos que forem extremas exceções (erros não conhecidos/esperados) no processo para o plantonista atuar, garantindo uma maior saúde na operação.

Automação de processos

Todo o processo que estiver causando Muda é alvo de automação, para que as pessoas possam trabalhar com mais agilidade. Bons exemplos de processos que costumam ser automatizados são:

• Deployment;
• Self-healing (resiliência do sistema em resposta às anomalias);
• Renovação de Certificados;
• Testes;
• Monitoramento (com auto-discovery);
• Governança de usuários;

DevOps toolchain

Uma combinação de ferramentas para facilitar a manutenção e operação do sistema, seguindo o seguinte fluxo:

Obs.: Qualquer semelhança com o PDCA é mera certeza.

• Plan: Fase de planejamento do projeto, em que são coletados os feedbacks para levantamento de requisitos, e criação do backlog;
• Create: Criação de um entregável (para validar uma hipótese), como um MVP;
• Verify: Passar o entregável para a fase de testes;
• Package: Empacotar o entregável (build) para conseguir colocar ele em algum ambiente de testes;
• Release: Fazer o deployment do entregável empacotado;
• Configure: Realizar a configuração do entregável no ambiente de testes, tentando chegar o mais próximo possível do twelve-factor app.
• Monitor: Após fazer o deployment no ambiente, acompanhar as métricas de negócio e infraestrutura, para garantir que está tudo funcionando conforme o esperado.

Conclusão

Durante a implementação dessas técnicas é possível observar melhoras no processo de desenvolvimento, os ganhos mais notáveis são:

• Melhoria no engajamento do time;
• Compartilhamento de conhecimento;
• Redução de bottlenecks;
• Mais tempo livre para realizar trabalho que realmente importa (agrega valor para a experiência do usuário ou gera impacto);
• Maior confiança ao entregar software.