DevOps
Rafael Azevedo
Desenvolvedor de Software em DINNI Soluções
Agenda
• Introdução
• Contexto
• Premissas
• DevOps
• Infraestrutura como código;
• Liderança;
• Burnout;
• Entrega contínua;
• Gerencia Lean;
• Práticas;
• Conclusão
• Bibliografia
Introdução
• DevOps é um termo cunhado para falar sobre a integração entre as
fases de desenvolvimento e implantação de software;
• Conceito diretamente relacionado a desempenho em TI: Em que
velocidade entregamos valor através dos sistemas que criamos?
• Dor causada por lançamento de versões pode ser uma boa métrica!
Contexto
• Os métodos tradicionais de desenvolvimento possuem uma lacuna
entre as fases de desenvolvimento e de implantação de software;
• Implantação de software costuma ser
• algo extremamente doloroso;
• demorado;
• pouco frequente;
• gera instabilidade no ambiente de produção;
Contexto
• DevOps se insere em um contexto onde é preferível lançar versões
com mais frequência e com pequenos incrementos, ao invés de
deixar acumular modificações e lançá-las todas de uma vez. Dessa
forma:
• Sistemas de software podem responder mais rapidamente às necessidades do
modelo de negócios;
• Menos mudanças  Menos riscos
• Maior entrega de valor;
• Vantagem de mercado;
Contexto
“Hoje em dia, as principais empresas estão se baseando quase que
totalmente em aplicações de software para entregar valor para seus clientes.
Para isso, essas empresas possuem modelos de negócio onde aplicações são
lançadas continuamente, de forma a testar seus modelos, e melhorarem.
Para isso, tanto os times de desenvolvimento quanto de infraestrutura
precisam estar afinados para responderem rápido a mudanças. Da mesma
forma que um software deve estar preparado para escalar, a infraestrutura
sob a qual ele esta rodando precisa estar preparada para o mesmo. A
infraestrutura precisa estar preparada para aguentar novas funcionalidades,
para ser reorganizada de acordo com o direcionamento que as entregas vão
dando para as aplicações”
Premissas
• Para que isso seja possível, é necessário:
• automatizar o máximo de tarefas possível relacionadas a implantação de
software;
• relação simbiótica entre equipes de desenvolvimento e implantação;
• arquitetura desenvolvida para suportar “testability” e “deployability”
• exemplo: microservices
• infraestrutura deve ser pensada nas fases iniciais;
• “fullstackers” – desenvolvedores conhecedores de toda a pilha de
desenvolvimento e com noção do impacto de suas ações nessa pilha;
DevOps
• DevOps propõe práticas que permitem facilitar a comunicação;
• Os times devem caminhar juntos para encontrar ferramentas e
processos em comum que ajudem ambos;
• Essa é a essência do movimento DevOps
DevOps
• Um papel importante: Coordenador de Lançamentos:
• responsável pela organização do lançamento de versões e pré-produção de
ambientes;
• Por que ele existe?
• Necessidade de coordenar lançamentos
• Complexidade crescente da infraestrutura
• Crescimento na taxa de lançamentos
• Equipes distribuídas
• Gerenciamento de mudanças - disciplina do ITIL
Infraestrutura como código e DevOps
• Virtualização
• É quando se escreve códigos e scripts para automatizar atividades
manuais que os times de infraestrutura deveriam executar
manualmente durante o processo de mudança. Trabalhar desta forma
faz com que os desenvolvedores se importem mais com infraestrutura
durante a construção de seus códigos e que equipe de implantação
antecipe-se e participe um pouco mais da etapa de desenvolvimento.
Infraestrutura como código e DevOps
• Um número enorme de falhas ocorre durante os processos de testes e
deploy em função das diferenças nos ambientes de desenvolvimento,
testes e produção. Pensar infraestrutura como código ajuda e muito
reduzir essas diferenças, já que fica fácil reproduzir ambientes de
produção;
• A ideia é que o próprio desenvolvedor consiga reproduzir facilmente
como seu código se comporta em produção;
Infraestrutura como código e DevOps
• Remove atritos de promoção das aplicações entre os ambientes;
• Melhora significativamente os tempos de entrega;
• Aumenta colaboração entre times;
Liderança e DevOps
• ROLE – Gerente de TI - conectar os objetivos estratégicos da empresa
com o trabalho que o time faz.
Quais os objetivos estratégicos da empresa que você trabalha ?
Liderança e DevOps
• Melhoria contínua: Líderes efetivos são aqueles que demonstram por suas
ações que a melhora do trabalho diário é mais importante que o trabalho
diário;
• Empoderamento: “Transportar a autoridade para onde a informação está.”
Isto é extremamente importante para escalar. As pessoas devem ter
autoridade para agir e elas podem agir sabiamente somente se elas tem
informação que elas precisam. Na verdade, muitas vezes são as pessoas lá
no operacional que sabem efetivamente o que deve ser feito. O papel do
líder deve ser confiar e possibilitar que aqueles que sabem o que precisa ser
feito, façam!
Burnout e DevOps
• Burnout é uma das consequências mais marcantes do estresse
profissional, caracterizando-se geralmente por exaustão emocional,
avaliação negativa de si mesmo, depressão e insensibilidade com
relação a quase tudo e todos (até como defesa emocional)
• O problema pode não estar nas pessoas, mas nos processos.
Burnout e DevOps
• Práticas de DevOps podem ajudar!
• Cultura organizacional: ambiente de trabalho respeitoso e que dê suporte;
• Plano de deploy: planos que evitem que o deploy de aplicações seja
estressante;
• Líder de equipe: exercer seu papel de distribuir de maneira balanceada carga
de trabalho e eliminar barreiras;
• Investimento em DevOps: investir na coordenação das equipes de
desenvolvimento e infraestrutura para planejar e tornar as implantações
menos dolorosas;
• Desempenho organizacional: Tem que ter tempo não só pra fazer, mas para
melhorar a forma de fazer;
Entrega contínua e DevOps
• O conjunto de praticas associadas com entrega contínua são
• Integração continua
• Testes automáticos
• Automatização de deploy
• Controle de versão para TODOS os artefatos em produção;
• Gerência de configurações;
Gerência Lean e DevOps
• Práticas de Lean relacionadas com DevOps
• Limitar trabalho em processo
• Controlar processo de implantação:
• Quanto tempo dura?
• Quantos bugs apareceram?
• Qual a frequência?
• Uso de ferramentas de monitoramento para tomar decisões de negócio;
Gerência Lean e DevOps
• Desenvolver qualidade no processo;
• Automatizando!
• Reduzindo tamanho das versões;
• Limitando ciclos de versões
• Gerenciando carga de trabalho, filas de prioridades, defeitos e gargalos.
• Resultado:
• + estabilidade
• + throughput
É possível começar do meio?
• Greenfield and brownfield
• O requisito maior é uma arquitetura de sistemas com suporte a
deployability e testability;
Práticas de DevOps
• Times multifuncionais
• Postura não orientada a culpa
• Responsabilidade compartilhada
• Quebrar barreiras entre papeis
• Tempo para experimentar
• Fluxo de informação
Práticas de DevOps
• Trunk-based development
• Ferramentas de gerencia de configuração;
• Metas em nível de organização ao invés de metas em nível de time
Conclusão
• O conceito de DevOps coloca em exposição as lacunas existentes entre
desenvolvimento e infraestrutura e estabelece meios de preencher
essas lacunas, considerando tanto o aspecto técnico quanto o aspecto
gerencial;
• As práticas consideradas estabelecem meios de abreviar o caminho
código em desenvolvimento – código em produção, aumentam a
velocidade com que valor é entregue através de software e reduzem o
impacto de incrementos em software em produção;
Bibliografia
• https://puppetlabs.com/sites/default/files/2015-state-of-devops-
report.pdf
• https://pt.wikipedia.org/wiki/DevOps
• http://computerworld.com.br/devops-o-ano-em-que-o-brasil-
descobriu-pratica-da-automacao-de-infraestrutura
• http://efetividade.net/2007/11/burnout-lidando-com-o-esgotamento-
pessoal-no-ambiente-de-trabalho.html

DevOps

  • 1.
    DevOps Rafael Azevedo Desenvolvedor deSoftware em DINNI Soluções
  • 2.
    Agenda • Introdução • Contexto •Premissas • DevOps • Infraestrutura como código; • Liderança; • Burnout; • Entrega contínua; • Gerencia Lean; • Práticas; • Conclusão • Bibliografia
  • 3.
    Introdução • DevOps éum termo cunhado para falar sobre a integração entre as fases de desenvolvimento e implantação de software; • Conceito diretamente relacionado a desempenho em TI: Em que velocidade entregamos valor através dos sistemas que criamos? • Dor causada por lançamento de versões pode ser uma boa métrica!
  • 4.
    Contexto • Os métodostradicionais de desenvolvimento possuem uma lacuna entre as fases de desenvolvimento e de implantação de software; • Implantação de software costuma ser • algo extremamente doloroso; • demorado; • pouco frequente; • gera instabilidade no ambiente de produção;
  • 5.
    Contexto • DevOps seinsere em um contexto onde é preferível lançar versões com mais frequência e com pequenos incrementos, ao invés de deixar acumular modificações e lançá-las todas de uma vez. Dessa forma: • Sistemas de software podem responder mais rapidamente às necessidades do modelo de negócios; • Menos mudanças  Menos riscos • Maior entrega de valor; • Vantagem de mercado;
  • 6.
    Contexto “Hoje em dia,as principais empresas estão se baseando quase que totalmente em aplicações de software para entregar valor para seus clientes. Para isso, essas empresas possuem modelos de negócio onde aplicações são lançadas continuamente, de forma a testar seus modelos, e melhorarem. Para isso, tanto os times de desenvolvimento quanto de infraestrutura precisam estar afinados para responderem rápido a mudanças. Da mesma forma que um software deve estar preparado para escalar, a infraestrutura sob a qual ele esta rodando precisa estar preparada para o mesmo. A infraestrutura precisa estar preparada para aguentar novas funcionalidades, para ser reorganizada de acordo com o direcionamento que as entregas vão dando para as aplicações”
  • 7.
    Premissas • Para queisso seja possível, é necessário: • automatizar o máximo de tarefas possível relacionadas a implantação de software; • relação simbiótica entre equipes de desenvolvimento e implantação; • arquitetura desenvolvida para suportar “testability” e “deployability” • exemplo: microservices • infraestrutura deve ser pensada nas fases iniciais; • “fullstackers” – desenvolvedores conhecedores de toda a pilha de desenvolvimento e com noção do impacto de suas ações nessa pilha;
  • 9.
    DevOps • DevOps propõepráticas que permitem facilitar a comunicação; • Os times devem caminhar juntos para encontrar ferramentas e processos em comum que ajudem ambos; • Essa é a essência do movimento DevOps
  • 10.
    DevOps • Um papelimportante: Coordenador de Lançamentos: • responsável pela organização do lançamento de versões e pré-produção de ambientes; • Por que ele existe? • Necessidade de coordenar lançamentos • Complexidade crescente da infraestrutura • Crescimento na taxa de lançamentos • Equipes distribuídas • Gerenciamento de mudanças - disciplina do ITIL
  • 11.
    Infraestrutura como códigoe DevOps • Virtualização • É quando se escreve códigos e scripts para automatizar atividades manuais que os times de infraestrutura deveriam executar manualmente durante o processo de mudança. Trabalhar desta forma faz com que os desenvolvedores se importem mais com infraestrutura durante a construção de seus códigos e que equipe de implantação antecipe-se e participe um pouco mais da etapa de desenvolvimento.
  • 12.
    Infraestrutura como códigoe DevOps • Um número enorme de falhas ocorre durante os processos de testes e deploy em função das diferenças nos ambientes de desenvolvimento, testes e produção. Pensar infraestrutura como código ajuda e muito reduzir essas diferenças, já que fica fácil reproduzir ambientes de produção; • A ideia é que o próprio desenvolvedor consiga reproduzir facilmente como seu código se comporta em produção;
  • 13.
    Infraestrutura como códigoe DevOps • Remove atritos de promoção das aplicações entre os ambientes; • Melhora significativamente os tempos de entrega; • Aumenta colaboração entre times;
  • 14.
    Liderança e DevOps •ROLE – Gerente de TI - conectar os objetivos estratégicos da empresa com o trabalho que o time faz. Quais os objetivos estratégicos da empresa que você trabalha ?
  • 15.
    Liderança e DevOps •Melhoria contínua: Líderes efetivos são aqueles que demonstram por suas ações que a melhora do trabalho diário é mais importante que o trabalho diário; • Empoderamento: “Transportar a autoridade para onde a informação está.” Isto é extremamente importante para escalar. As pessoas devem ter autoridade para agir e elas podem agir sabiamente somente se elas tem informação que elas precisam. Na verdade, muitas vezes são as pessoas lá no operacional que sabem efetivamente o que deve ser feito. O papel do líder deve ser confiar e possibilitar que aqueles que sabem o que precisa ser feito, façam!
  • 16.
    Burnout e DevOps •Burnout é uma das consequências mais marcantes do estresse profissional, caracterizando-se geralmente por exaustão emocional, avaliação negativa de si mesmo, depressão e insensibilidade com relação a quase tudo e todos (até como defesa emocional) • O problema pode não estar nas pessoas, mas nos processos.
  • 17.
    Burnout e DevOps •Práticas de DevOps podem ajudar! • Cultura organizacional: ambiente de trabalho respeitoso e que dê suporte; • Plano de deploy: planos que evitem que o deploy de aplicações seja estressante; • Líder de equipe: exercer seu papel de distribuir de maneira balanceada carga de trabalho e eliminar barreiras; • Investimento em DevOps: investir na coordenação das equipes de desenvolvimento e infraestrutura para planejar e tornar as implantações menos dolorosas; • Desempenho organizacional: Tem que ter tempo não só pra fazer, mas para melhorar a forma de fazer;
  • 18.
    Entrega contínua eDevOps • O conjunto de praticas associadas com entrega contínua são • Integração continua • Testes automáticos • Automatização de deploy • Controle de versão para TODOS os artefatos em produção; • Gerência de configurações;
  • 19.
    Gerência Lean eDevOps • Práticas de Lean relacionadas com DevOps • Limitar trabalho em processo • Controlar processo de implantação: • Quanto tempo dura? • Quantos bugs apareceram? • Qual a frequência? • Uso de ferramentas de monitoramento para tomar decisões de negócio;
  • 20.
    Gerência Lean eDevOps • Desenvolver qualidade no processo; • Automatizando! • Reduzindo tamanho das versões; • Limitando ciclos de versões • Gerenciando carga de trabalho, filas de prioridades, defeitos e gargalos. • Resultado: • + estabilidade • + throughput
  • 21.
    É possível começardo meio? • Greenfield and brownfield • O requisito maior é uma arquitetura de sistemas com suporte a deployability e testability;
  • 22.
    Práticas de DevOps •Times multifuncionais • Postura não orientada a culpa • Responsabilidade compartilhada • Quebrar barreiras entre papeis • Tempo para experimentar • Fluxo de informação
  • 23.
    Práticas de DevOps •Trunk-based development • Ferramentas de gerencia de configuração; • Metas em nível de organização ao invés de metas em nível de time
  • 24.
    Conclusão • O conceitode DevOps coloca em exposição as lacunas existentes entre desenvolvimento e infraestrutura e estabelece meios de preencher essas lacunas, considerando tanto o aspecto técnico quanto o aspecto gerencial; • As práticas consideradas estabelecem meios de abreviar o caminho código em desenvolvimento – código em produção, aumentam a velocidade com que valor é entregue através de software e reduzem o impacto de incrementos em software em produção;
  • 25.
    Bibliografia • https://puppetlabs.com/sites/default/files/2015-state-of-devops- report.pdf • https://pt.wikipedia.org/wiki/DevOps •http://computerworld.com.br/devops-o-ano-em-que-o-brasil- descobriu-pratica-da-automacao-de-infraestrutura • http://efetividade.net/2007/11/burnout-lidando-com-o-esgotamento- pessoal-no-ambiente-de-trabalho.html