Escalando times e salvando casamentos com continuous delivery by @brunogh @ RubyConf Braisil 2015

Nessa palestra mostraremos como práticas relacionadas à entrega contínua nos ajudaram em um processo de grande crescimento e reestruturação – em que passamos de um time único atendendo a 300 clientes, a um cenário com mais de 1800 clientes com cinco 5 equipes trabalhando no mesmo produto.
O segredo foi simples na sua essência, mas difícil na aplicação: Continuous Delivery. Com o crescimento da empresa, o ciclo de desenvolvimento tinha se tornado o grande gargalo a ser vencido – deploys que não escalavam, processos manuais e relacionamentos pessoais quase destruídos por horas excessivas de trabalho. Hoje realizamos 10 deploys diários, temos maior qualidade do produto entregue e clientes e equipes bem mais satisfeitas.
Serão abordados tópicos que vão desde a forma em que temos utilizado controle de versão, passando por práticas e ferramentas adotadas no desenvolvimento e testes das funcionalidades, até como realizamos o revert de versões em produção. Veremos processos e soluções que podem servir de inspiração para você iniciar sua jornada na busca da entrega contínua.

Transcript

1. Escalando times e salvando casamentos com continuous delivery Bruno Ghisi @brunogh shipit.resultadosdigitais.com.br
2. Bruno Ghisi CTO, Resultados Digitais @brunogh
3. RD Station
4. 2012 2011 2012 2013 2014 hoje
6. +3000 clientes RDSummit.com.br
7. + 200 RDoers
8. 2012 2011 2012 2013 2014 hoje CASEI
11. 300 clientes
12. 300 clientes 7 devs 1 time
13. 1. branch do master 2. dev, dev, dev 3. abrir PR 4. review 5. teste em staging 6. merge master 7. deploy
14. EU fazia review, teste, merge e deploy!
15. 1. branch do master 2. dev, dev, dev 3. abrir PR 4. review 5. teste em staging 6. merge master 7. deploy
16. WAT?
20. Não escala!
21. Merge/deploy dos outros não é simples
22. Merge/deploy dos outros não é simples Centralizar é falta de confiança
23. Merge/deploy dos outros não é simples Centralizar é falta de confiança Gargalo para gerar valor
24. Merge/deploy dos outros não é simples Centralizar é falta de confiança Gargalo para gerar valor Cultura ruim
25. Empower People
26. as pessoas irão fazer cagadas
27. #1 Melhorar o processo
28. Testes e Cobertura
29. Integração Contínua
30. Circle CI
32. Métricas
33. Code Climate
35. Code review
38. as pessoas irão fazer cagadas #2
39. #2 Automatizar
40. The Capybot
42. +
45. via slack.com
46. 1. branch do master 2. dev, dev, dev 3. abrir PR 4. review por alguém do time 5. deploy via Capybot 6. merge master
47. Quem abriu o PR é responsável por levá-lo a produção
49. Todos felizes
50. as pessoas irão fazer cagadas #3
51. #3 nova cultura
52. Devops
53. QA
54. compartilhar aprendizado entre os times
55. #1 processo #2 automatizar #3 cultura
56. e como se recuperar dos problemas?
57. local staging prod
58. 1) Testes Database forks
59. 1) Testes Database forks PRs incrementais
60. 1) Testes Database forks PRs incrementais Canary deployment
61. 2) Plano B Horário e roteiro
62. 2) Plano B Horário e roteiro Estratégia de rollback (automático e scripts)
63. In God we trust, all the others must bring DATA
64. New Relic Librato
65. Don't call us, we will call you
66. Log Entries Rollbar
67. se você está fazendo algo que não escala, comece a mudar hoje
68. se você está fazendo algo que não escala, comece a mudar hoje e salve seu relacionamento!
69. Bruno Ghisi @brunogh bruno.ghisi@resultadosdigitais.com.br shipit.resultadosdigitais.com.br