4. Como falam por aí:
“DevOps é um método para
desenvolvimento de Software que enfatiza a
comunicação, colaboração, integração,
automação e o uso de métricas.”
Patrick Debois
5.
6. “DevOps é um método para desenvolvimento
de Software que enfatiza a comunicação,
colaboração, integração, automação e o uso
de métricas.”
Patrick Debois
https://blog.newrelic.com/2014/05/16/devops-name/
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
8. Workshop em 2011
"E se jogarmos nosso servidor de produção pela janela?"
"Quanto tempo para colocar o sistema novamente no ar?"
"Continuous Delivery for DevOps"
Jez Humble / Agosto - 2011
Rio de Janeiro
14. “O principal objetivo é aumentar a
colaboração entre os envolvidos no
processo de entrega de software,
de um modo que possamos entregar valor
mais rápido e de modo mais confiável”
Patrick Debois
15.
16. E por que isso faz tanto sentido?
(Lead time = tempo total) > 30 dias!!!!
A gente pode esperar?
23. 1) Produz vários documentos para mandar para outro setor,
afinal tudo deve ser bem documentado para servir de “evidência”?
2) Nas “salas de guerra”, é comum haver trocas de acusações
constantes?
3) Alguém sempre diz que não pode ser feito porque a lei SOX não
permite, o ITIL não deixa etc?
4) Você convida com constância os membros de outras
“especialidades” para ajudar no seu trabalho?
5) Somos preocupados com o Kaizen, sempre estamos reunindo os
vários times envolvidos no projeto para levantarmos pontos de
melhoria?
Vamos ver como estamos no teste do
“Wall of Confusion”:
livremente inspirado de http://itrevolution.com/devops-culture-part-2/
24.
25. Beleza!
Só derrubarmos as barreiras então!
“You can’t directly change culture. But you can
change behavior, and behavior becomes
culture”
Lloyd Taylor
26.
27. Cavernas (silos) de conhecimento...
Mito do herói!
Na prática, é o
famoso funcionário
que perdeu o
direito de morrer! :(
33. Infra as Code (Puppet, chef, Docker etc)
Gerência de configuração “automatizada"
● Infrastructure as Code: Track, Test, Deploy, Reproduce, Scale
● Qualquer alteração de código gera log e histórico de mudança na
infraestrutura
● Setups "repetitíveis": Do once, repeat forever
● Escalabilidade mais rápida: Uma instância configurada é o mesmo custo
que configurar várias
● Coerência e consistência nos setups dos vários servidores
● Ambientes consistentes: Dev, QA, Homolog, Prod
Alternativas ao Puppet: Chef, Salt, Ansible
34.
35. Infra as Code (Puppet, chef, Docker etc)
Inclusive para Windows!
45. Continuous Delivery
Build -> Fase de Integração contínua
Deploy -> Ferramentas Infra as Code
Test -> Smoke Tests, sondas
automatizadas de monitoramento
Release -> Processo automatizado de
release para usuários
(ler sobre feature flags, canary
releasing, blue green deployment)
46. De onde surgiram as idéias do CD?
● Idéias vindas do artigo
○ The Deployment Production Line
■ Jez Humble, Chris Read, Dan North
■ AGILE '06 proceedings of the conference - IEEE
Computer Society , Pages 113 - 118
47. "The Problems of delivering Software"
● Deploy manual
● Deploy em homologação
● Configuração manual do ambiente de produção
● Feedback de pequenos grupos de usuários
● "Done Means Released" (Jez Humble)
● Controle de versão
● Gerenciamento de dependências
48. ● Gerenciamento de configuração do software
● Ferramentas para automatizar e gerenciar qualquer
aspecto relacionado ao software!
○ DDL/DML do Banco de dados
○ Máquinas virtuais
■ Servidores de aplicação
○ Infraestrutura de rede
○ Load-Balancing "elástico"
■ Behavior-Driven Monitoring
○ Deploy da aplicação