Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TDC2018FLN | Trilha Ruby - Como turbinamos nossa sua suite de testes Rails em mais de 600%

52 views

Published on

Como turbinamos nossa sua suíte de testes Rails em mais de 600%

Published in: Education
  • Be the first to comment

TDC2018FLN | Trilha Ruby - Como turbinamos nossa sua suite de testes Rails em mais de 600%

  1. 1. Como Turbinamos nossa suíte de testes Rails em mais de 600% TDC Florianópolis 2018 - Trilha Ruby
  2. 2. Tecnólogo em Gestão de TI SysAdmin que aprendeu a programar Nascido em Brasília mas feito na Bahia, Louco por automação, músico do buteco da esquina, marceneiro de fim de semana. $> whoami Eric Magalhães DevOps Evangelist @ JobScore Inc Joinville - SC - Brazil
  3. 3. Bacharel em Ciência da Computação - FURB Mestre em Informática - UFPR Desenvolvedor Rails desde 2008 Mantenedor - RubyGem Octopus $> su thiago $> whoami Thiago Pradi Lider Técnico @ JobScore Inc Jaraguá do Sul - SC
  4. 4. Agenda ● Problema ● A solução ● Conclusão ● Background ● Desafios ● Setups antigos
  5. 5. Agenda ● Problema ● A solução ● Conclusão ● Tentativa e erro ● Testes em paralelo ● Implementação ● Melhoria
  6. 6. Agenda ● Problema ● A solução ● Conclusão ● Considerações finais
  7. 7. Um Pouco de História Problema
  8. 8. JobScore (www.jobscore.com) “Software de Recrutamento” (ATS) Criada em 2005 utilizando Rails 0.5 Problema
  9. 9. Problema
  10. 10. Problema
  11. 11. 13 anos de história em números Profitable ($$$) Mais de 15 Bilhões em aquisições Mais de 1M de aplicações Problema
  12. 12. Stack Atual Ruby on Rails / Python PostgreSQL / MySQL / Redis Passenger / AWS Problema
  13. 13. Antes de 2012/2013... Problema
  14. 14. Decisões Antigas de Engenharia (exemplo: Fat Controllers) Problema
  15. 15. Criação de dados para testes utilizando somente Fixtures Problema
  16. 16. Ausência de testes de Aceitação Utilização de testes de Integração Problema
  17. 17. Problema
  18. 18. Coverage abaixo da média (< 50%) Problema
  19. 19. Abuso de soluções temporárias (rescue nil, monkeypatches, gems antigas) Problema
  20. 20. Problema
  21. 21. 2013: Adotadas práticas mais modernas na suíte de testes Problema
  22. 22. Stack da suíte de testes Minitest (migrado do test/unit) Aceitação - Capybara / Poltergeist Dados - Fixtures/Factories Problema
  23. 23. 2016/2017: problemas diferentes Problema
  24. 24. Testes lentos pelo abuso de Factories Problema
  25. 25. Testes quebradiços devido ao exagero de testes de aceitação com Capybara / Poltergeist Problema
  26. 26. Builds levando mais de uma hora. Problema
  27. 27. Solução: Utilização de servidor de integração contínua. Problema
  28. 28. 1) Jenkins - Self-hosted; 2) Semaphore; 3) Circle CI; 4) Travis. Problema
  29. 29. Testes divididos em 4 “workers” pelo tipo do mesmo (unitário, aceitação, controller e mailers) Problema
  30. 30. Alto Custo para upgrades. Espera de quase 1 hora para cada merge. Problema
  31. 31. A Solução
  32. 32. Contratado para ser owner de várias coisas, incluindo o CI Histórico
  33. 33. Nenhum Pouco conhecimento sobre testes para Rails Histórico
  34. 34. Primeiro objetivo: Testes em menos de 10 minutos Histórico
  35. 35. Primeiros erros
  36. 36. Manter o paralelismo existente usando Jenkins + EC2 Primeiros erros
  37. 37. 2 vCPU / 4GB = 35min 8 vCPU / 16GB = 4x faster Primeiros erros
  38. 38. Primeiros erros
  39. 39. Primeiros erros
  40. 40. Paralelismo é a solução! Primeiros erros
  41. 41. Estratégia: Ambientes isolados em uma máquina maior Primeiros erros
  42. 42. Testes com Docker Primeiros erros
  43. 43. Sai Jenkins e entra Buildbot Primeiros erros
  44. 44. Builds independentes Primeiros erros
  45. 45. Testes ainda demoravam demais Entre 5-16min Primeiros erros
  46. 46. Primeiros erros
  47. 47. https://github.com/grosser/parallel_tests Testes em paralelo
  48. 48. Setup relativamente simples Testes em paralelo
  49. 49. Os tempos eram bons! Testes em paralelo
  50. 50. Primeiros erros
  51. 51. Implementação
  52. 52. Testes problemáticos falham com mais frequência Implementação
  53. 53. Auto-retry: Minitest reporter + script em Python Implementação
  54. 54. Três categorias de teste: Pass Danger Fail Melhoria contínua
  55. 55. Usando instâncias spot Por volta dos USD 300 Custo
  56. 56. Tempos atuais 1-2 min Preparando ambiente de teste Criar banco, rodar migrations, testes javascript 1-2 min Dependências Tempo para baixar as dependências do código (Gems, NPM, etc.) 3-5 min Boot Tempo de boot de uma instância EC2 4-6 min Testes Tempo para rodar todos os testes
  57. 57. Em torno de 10h/mês Operação / Manutenção
  58. 58. Como monitorar o CI? Melhoria contínua
  59. 59. Metrics to the rescue! Melhoria contínua
  60. 60. O CI precisa de carinho Melhoria contínua
  61. 61. Conclusão Solução
  62. 62. Aplicações antigas requerem manutenção constante. Solução
  63. 63. Manutenções incluem refatorar código ou inclusão de novas tecnologias. Solução
  64. 64. Suas soluções irão refletir no futuro, de forma positiva ou negativa. Solução
  65. 65. Por isso, saiba medir os prós e contras de cada solução. Solução
  66. 66. Solução https://weblog.rubyonrails.org/2018/2/17/this-week-in-rails-rails-5-1-5-pa rallel-testing-and-more/
  67. 67. https://github.com/rails/rails/pull/31900
  68. 68. $> su ericovis -c 'whereis ${USER}' Social media: @ericovis Web: https://emagalha.es Email: eric@emagalha.es
  69. 69. $> su thiago -c 'whereis ${USER}' Social media: @thiagopradi Web: https://www.thiagopradi.com Email: thiago.pradi@gmail.com
  70. 70. Wrap up

×