Em posts anteriores, compartilhei o Timeline DevOps com os principais marcos que ajudaram na alavancagem das práticas DevOps, também um resumo da Jornada DevOps e seus principais benefícios. Neste post, vamos abordar conceitos iniciais importantes e como evitar algumas “armadilhas” nas implementações.

O ponto inicial é a definição sobre DevOps. Aqui sempre há confusão em relação ao que será implementado, o problema a ser resolvido, as ferramentas utilizadas (DevOps não é somente uso de ferramentas), etc. É importante começar certo! Abaixo, compartilho a definição O que é DevOps de duas das maiores empresas do mundo – Microsoft e AWS.

O que é DevOps

By Microsoft

É a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais. A contração de “Dev” e “Ops” refere-se à substituição do Desenvolvimento e Operações em silos para criar equipes multidisciplinares que agora trabalham em conjunto com práticas e ferramentas compartilhadas e eficientes. As práticas essenciais do DevOps incluem planejamento ágil, integração contínua, entrega contínua e monitoramento de aplicativos.

By AWS: é a combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma empresa de distribuir aplicativos e serviços em alta velocidade: otimizando e aperfeiçoando produtos em um ritmo mais rápido do que o das empresas que usam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura. Essa velocidade permite que as empresas atendam melhor aos seus clientes e compitam de modo mais eficaz no mercado.

Em resumo, gosto de compartilhar a seguinte visão consolidada sobre DevOps:

Colaboração e comunicação Melhorar a colaboração e comunicação entre as equipes de Dev e Ops

Qualidade e segurança Entrega frequente de valor aos clientes com qualidade e segurança

O que não é DevOps

E como cada área da organização até então entendia DevOps? Tudo isso (desenho abaixo) representa uma visão muito segmentada, ou parcial, sobre o entendimento de DevOps. Por isso, a visão consolidada (comentada anteriormente) é tão importante. É comum, por exemplo, equipes de desenvolvimento associarem práticas DevOps apenas com a automação de tarefas como de build e release.

Leia mais sobre os três pilares DevOps (Pessoas, Processos e Ferramentas): Link 1 | Link 2 | Link 3.

DevOps Tricks

Entre as principais armadilhas das implementações DevOps estão:

• “I Know DevOps”: como DevOps vai muito além do uso de ferramentas, a cultura organizacional (aprendizado contínuo) e o desenvolvimento do time são essenciais para evitar problemas técnicos e com pessoas (ambiente colaborativo e sem silos).
• “Immigration is a lot like DevOps, you need containers”: outro erro clássico é simplesmente buscar soluções sem antes verificar a aplicabilidade ao seu ambiente ou até mesmo o nível de maturidade do time para utilizá-las.
• “What if I told you, DevOps and Agile are not the same thing”: é comum ver em alguns eventos a associação do ciclo Ágil ao DevOps. É uma combinação que pode funcionar muito bem sim, mas não confunda com um depender do outro.
• “Worked fine in Dev – ops problem now”: o típico erro de gestão de configuração, ambientes e integração contínua. Na máquina do desenvolvedor sempre funciona!

Pipeline de implantação

O termo pipeline é muito utilizado em DevOps, pois é onde está o foco em automatizar os processos e garantir a entrega contínua de aplicações em produção com eficiência e confiabilidade. Em geral, o processo na empresa para lançamento de um produto (ou nova funcionalidade) é:

1. Visão do produto: o que é esta nova funcionalidade
2. Time de Dev: realizar o desenvolvimento iterativo e incremental de uma nova versão a cada iteração
3. Área de operação: implementação e manutenção
4. Geração de valor para o cliente

O Fluxo de valor cobre desde a concepção do produto até a geração de valor para a empresa. A última milha é extremamente importante neste contexto, pois considera aspectos da entrega do produto, tais como a configuração de ambientes e automação de testes.

As práticas DevOps são essenciais para criar o pipeline de implantação, disponibilizando novas versões de software o tempo todo ao cliente. O Feedback contínuo vai guiando a estratégia da empresa, eliminando barreiras entre os departamentos. Isso permite a colaboração entre as pessoas para gerar valor ao cliente.

Antipatterns DevOps

Antipatterns do Deploy Manual

Livro Continuous Delivery (Jez Humble David Farley)

Documentação extensa com os passos a serem seguidos e procedimento de rollback em caso de falha Confiança em testes manuais p/ confirmar o funcionamento das aplicações Correções frequentes na implementação da release Ambientes em cluster com configurações diferentes (por exemplo: servidores de aplicação com diferente connection pool settings, etc.) Releases com resultado imprevisível (e necessitam de frequentes rollbacks para resolver problemas)

Antipatterns de Gestão da Configuração Manual

Livro Continuous Delivery (Jez Humble David Farley)

Deploy frequentemente bem sucedido em staging, mas falha no ambiente de produção Demora na preparação de ambiente Impossibilidade de retornar a uma configuração anterior da aplicação (OS, application server, RDBMS, etc). “In software, when something is painful, the way to reduce the pain is to do it more frequently, not less. So instead of integrating infrequently, we should integrate frequently”.

 

Nos posts recentes, descrevemos alguns cenários de Transformação digital – análise e tendências e os Desafios organizacionais em entrega contínua – time-to-market e exponencial. Evoluir em práticas DevOps é uma prioridade comum para as empresas com foco em crescimento e inovação.

E como surgiu o uso do DevOps nas empresas? Qual era o problema a ser resolvido com a adoção destas práticas? Criei então um timeline com os principais marcos e evoluções que fizeram o DevOps estar presente no Gartner Hype Cycle (em 2015) e na agenda de estratégia das principais empresas.

• 2007: primeiras iniciativas em um projeto de migração de data center. Patrick Dubois (Bélgica) propõe a criação de um time de DevOps para melhorar a integração e eficiência entre o time de desenvolvimento e operações, pois havia um grande gargalo um problema na cadeia de entrega.
• 2008: Patrick Debois apresenta na Agile Conference (Toronto/CA) um modelo para solucionar os conflitos entre as áreas de desenvolvimento e operações de TI, com foco em dar mais agilidade à área de infraestrutura.
• 2009: Allspaw & Paul Hammond apresentam no Velocity (San Jose/CA) 10+ Deploys per day, propondo um novo modelo operacional para atender as mudanças nos negócios. E assim, mudar a forma: “Dev’s job is to add new features; Ops’ job it to keep the site stable and fast”.
• 2011-2012: líderes do setor de software (IBM, CA Technologies, etc.) aumentam a presença de DevOps tools no mercado empresarial.
• 2013: o livro The Phoenix Project, entre outros, traz conceitos de CI (Continuous Integration), CD (Continuous Delivery e Deployment), fundamentais para a propagação das práticas até hoje.
• 2014: começa a gerar impacto positivo na área de TI – benefícios do DevOps.
• 2015: presença no Gartner Hype Cycle.

Gartner Hype Cycle
O hype cycle identifica cinco estágio no ciclo de vida tecnológico. Em 2015, o DevOps estava em Peak of Inflated Expectations, fase caracterizada pelo uso de early adapters. E com projeção de 5-10 anos para atingir Plateau of Productivity e assim ser largamente implementada.

State of DevOps Report
O Report Puppet Labs indica que times utilizando práticas DevOps:

• Aumentaram a frequência dos deploys em 30 x
• Com lead time reduzido em 200 x
• Qualidade: redução em 60 x de falhas
• Recuperação de problemas 168 x mais rápido

* esta pesquisa considerou empresas de diferentes tamanhos e segmentos.

Além de lidar com os Desafios organizacionais em entrega contínua – time-to-market e exponencial, as empresas também recorrem as práticas DevOps para manterem-se competitivas em Continuous Delivery, disponibilizando novas releases o tempo todo no mercado para validação de hipóteses (conceito explorado no Build-Measure-Learn-Loop do Lean Startup).

Mesmo em cenários completamente diferentes, as startups e as empresas grandes realizam análise financeira (de acordo com o seu modelo) para justificar o investimento em novas iniciativas. Para criar novos produtos, o racional geralmente é justificado pela aquisição de novos clientes, aumento de receita, market share, entre outros.

Já em investimentos que visam melhorias nos processos internos, como por exemplo, métodos ágeis e práticas DevOps, as empresas se deparam com a seguinte pergunta: qual o problema a ser resolvido? Muitas vezes são retornos qualitativos, necessários para aumentar o valor do negócio.

O problema a ser resolvido
As empresas tradicionalmente possuíam na área de TI uma equipe de operações com a responsabilidade de manter os ambientes estáveis e resilientes (qualquer alteração deve ser feita com muito cuidado). E outra equipe de desenvolvimento que precisa responder rapidamente às necessidades do negócio. E ambas precisam contribuir para o sucesso do negócio!

Entre os principais problemas de equipes que não adotaram DevOps estão:

▫Erro manual é comumente identificado com causa raiz

▫Defeitos são liberados a produção, causando interrupções ▫Incapacidade de diagnosticar problemas em produção rapidamente ▫Problemas em um ambiente específico ▫Blame shifting / finger pointing ▫Dificuldade em colocar releases em produção

E por que as empresas investem em DevOps?
O  TechValidate traz alguns estudos de caso de grandes empresas, tais como Grupo Boticário, Santander e HMS. Ele descreve os desafios e resultados de cada organização ao adotar práticas DevOps. Na imagem abaixo, os principais motivos do Boticário e Santander estarem investindo em transformação com DevOps:

Fonte: https://www.techvalidate.com/product-research/ca-devops/case-studies