O documento introduz os conceitos de DevOps e Continuous Delivery. Resume que DevOps enfatiza a comunicação, colaboração, integração e automação entre equipes de desenvolvimento e operações. Apresenta também a importância da infraestrutura como código e do deploy contínuo para entregar valor de forma mais rápida e confiável.

1. Introdução a DevOps e
Continuous Delivery
Carlos Felippe Cardoso (CFC)
cfc@k21.com.br
@carlosfelippe
slideshare.net/cfelippe
k21.com.br

2. Do que vamos falar?
1. Conceito de DevOps
2. Disfunções comuns
3. Por que adotarmos?
4. Infra as Code
5. Continuous Delivery

3. Pra começar, o que é DevOps?

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

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

7. Um bom livro
pra entender a
relação entre
DevOps, Agile
etc?

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

9. Você já viu isso acontecer?

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

16. E por que isso faz tanto sentido?
(Lead time = tempo total) > 30 dias!!!!
A gente pode esperar?

17. Enquanto isso...

19. DevOps não resolve só os problemas
técnicos.
Resolve os de negócio!

20. Pontos-chave para adotarmos
1) Diminuir “Time-to-market”
2) Melhoria na qualidade
3) Aumentar resiliência

21. “Mas CFC, aqui na empresa é
diferente…”

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/

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

27. Cavernas (silos) de conhecimento...
Mito do herói!
Na prática, é o
famoso funcionário
que perdeu o
direito de morrer! :(

28. A transição entre DevOps
como prática / cultura leva tempo...

29. E por onde começar?

30. Pilares e práticas para DevOps
May Xu

31. Infra as Code (Puppet, chef, Docker etc)

32. Perfil
profissional
diferente!

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

35. Infra as Code (Puppet, chef, Docker etc)
Inclusive para Windows!

36. E como é código...
Integração Contínua!

37. Infra as code
Puppet Script
Cloud
Provisiona
Máquina em
Staging
Scripting Tudo OK?
(testing)

38. Dashboards!
Nem sempre está verde! =(

39. Dashboards!

40. E pode ir até produção!

41. E o deploy automatizado?
Que tal " tão" simples quanto o apertar de um botão?
Fabric

42. E o deploy automatizado?
Que tal " tão" simples quanto o apertar de um botão?

43. Continuous Integration -> Continuous Delivery

44. Pipeline de Build

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

49. Vamos sonhar alto?

50. Continuous Delivery & DevOps

51. PERGUNTAS?
cfc@k21.com.br
@carlosfelippe
slideshare.net/cfelippe
k21.com.br/treinamentos/