CULTURA DEVOPS@leocomelli

Leonardo Comelli@leocomelli

porque estamos aqui?software vs sistema

o mais importante é…

entregar valor para o cliente!

mas isso precisa ser feito com:rapidez | segurança | confiabilidade

nada é perfeito, as coisas podem falhar...

qual o segredo?

falhar rápido!

como falhar rápido?desenvolvimento ágil | entrega contínua | análise da operação

dev opsesse fluxo envolve os dois times

porque toda essa distância?existe um conflito de interesse

alteraré o papel do dev

estabilizaré o papel de ops

devnão publicam software consistente

opssão resistentes a mudanças

devprocesso ágil

opsprocesso estático

dev“na minha máquina funciona…"

ops“não é o servidor, é o seu código…"

é necessário unir os times

feito! isso é devops!

não!

dev opsdevops não é juntar os times

devops não é o time de opsdesenvolver um sistema para substituir os demais

devops não é o time de opscriar um ambiente de uma maneira simples

devops não é o time de opssaber o que o time de dev quer

devops não é o time de devsaber utilizar uma ferramenta de aprovisionamento

devops não é o time de devcriar um script para publicar uma nova versão

devops não é o time de devsaber o que o time de ops quer

devops não é apenasferramentas, automação, acessos e time

os princípios são maiores que as práticas

devops écomunicação, entendimento, integração e relacionamento

devops é cultura!

devops é uma cultura de colaboração entre desenvolvedores e operações

[in]felizmente devops não é uma opção

precisamos de tudo muito rápidoalterações, publicações, identificação de problemas, correções

lembre-se, falhar é normal o segredo é falhar rápido!

o que pode nos auxiliar a falhar rápido?ferramentas e automatizações

pipeline!um exemplo

executar testesintegração

executar testesunitários

obter dados doversionador

compilar códigofonte

publicar em homologaçãoempacotar

gerar documentação

publicar em produção

executar testes de aceitação

publicaçãodeploy com bug zero?

publicaçãoblue/green deployment

https://blog.snap-ci.com/blog/2015/06/22/continuous-deployment-strategies

publicaçãocanary deployment

https://blog.snap-ci.com/blog/2015/06/22/continuous-deployment-strategies

o trabalho não acaba após o deploy

operation analyticsmonitoramento

ferramentasalguns exemplos

sistema de controle de versãosvn, tfs, git, etc

$  git  init  

$  touch  README.md  

$  git  add  .  

$  git  commit  -­‐m  “Criado  arquivo  readme”  

$  git  remote  add  origin  https://github.com/user/repo.git  

$  git  push  -­‐u  origin  master

infra como códigoansible, chef, puppet, etc

-­‐-­‐-­‐  -­‐  name:  create  user  group      sudo:  yes      group:          name:  "hpe_apps"          state:  present  

-­‐  name:  add  server  user      sudo:  yes      user:          name:  "comelli"          password:  secret          system:  yes          group:  "hpe_apps"          state:  present

virtualizaçãodocker, vagrant, vmware

#  Pull  base  image.  FROM  ubuntu  

#  Install  Ruby.  RUN  \      apt-­‐get  update  &&  \      apt-­‐get  install  -­‐y  ruby  ruby-­‐dev  ruby-­‐bundler  &&  \      rm  -­‐rf  /var/lib/apt/lists/*  

#  Define  working  directory.  WORKDIR  /data  

#  Define  default  command.  CMD  ["bash"]  

orquestração de containermesos, kubernetes, swarm, etc

integração contínuatravis, jenkins, go, etc

entrega e deploy contínuotravis, jenkins, go, etc

entrega contínua != deploy contínuo

operation analyticslogstash, elasticsearch e kibana

esta pronto para o devops?

Obrigado!http://slideshare.net/leocomelli

Bônus!git, docker, jenkins, travis ou kibana?