O documento descreve como a suíte de testes do aplicativo web JobScore foi aprimorada para rodar mais de 600% mais rápido. O problema era que os testes levavam mais de uma hora para rodar. A solução foi dividir os testes em ambientes Docker isolados e executá-los em paralelo usando a ferramenta Buildbot em vez do Jenkins. Isso reduziu o tempo de teste para entre 3-10 minutos. Monitoramento contínuo e melhorias adicionais reduziram ainda mais o tempo.

1. Como Turbinamos nossa suíte de
testes Rails em mais de 600%
TDC Florianópolis 2018 - Trilha Ruby

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. 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. Agenda
● Problema
● A solução
● Conclusão
● Background
● Desafios
● Setups antigos

5. Agenda
● Problema
● A solução
● Conclusão
● Tentativa e erro
● Testes em paralelo
● Implementação
● Melhoria

6. Agenda
● Problema
● A solução
● Conclusão
● Considerações finais

7. Um Pouco de História
Problema

8. JobScore (www.jobscore.com)
“Software de Recrutamento” (ATS)
Criada em 2005 utilizando Rails 0.5
Problema

9. Problema

10. Problema

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. Stack Atual
Ruby on Rails / Python
PostgreSQL / MySQL / Redis
Passenger / AWS
Problema

13. Antes de 2012/2013...
Problema

14. Decisões Antigas de Engenharia
(exemplo: Fat Controllers)
Problema

15. Criação de dados
para testes
utilizando
somente Fixtures
Problema

16. Ausência de testes
de Aceitação
Utilização de testes
de Integração
Problema

17. Problema

18. Coverage abaixo da média (< 50%)
Problema

19. Abuso de soluções
temporárias
(rescue nil, monkeypatches,
gems antigas)
Problema

20. Problema

21. 2013: Adotadas práticas mais
modernas na suíte de testes
Problema

22. Stack da suíte de testes
Minitest (migrado do test/unit)
Aceitação - Capybara / Poltergeist
Dados - Fixtures/Factories
Problema

23. 2016/2017:
problemas diferentes
Problema

24. Testes lentos pelo abuso de
Factories
Problema

25. Testes quebradiços devido ao
exagero de testes de aceitação
com Capybara / Poltergeist
Problema

26. Builds levando mais de uma hora.
Problema

27. Solução: Utilização de servidor de
integração contínua.
Problema

28. 1) Jenkins - Self-hosted;
2) Semaphore;
3) Circle CI;
4) Travis.
Problema

29. Testes divididos
em 4 “workers” pelo
tipo do mesmo
(unitário, aceitação,
controller e mailers)
Problema

30. Alto Custo para upgrades.
Espera de quase 1 hora para cada
merge.
Problema

31. A Solução

32. Contratado para ser owner de
várias coisas, incluindo o CI
Histórico

33. Nenhum Pouco conhecimento
sobre testes para Rails
Histórico

34. Primeiro objetivo: Testes em
menos de 10 minutos
Histórico

35. Primeiros erros

36. Manter o paralelismo existente
usando Jenkins + EC2
Primeiros erros

37. 2 vCPU / 4GB = 35min
8 vCPU / 16GB = 4x faster
Primeiros erros

38. Primeiros erros

39. Primeiros erros

40. Paralelismo é a solução!
Primeiros erros

41. Estratégia: Ambientes isolados
em uma máquina maior
Primeiros erros

42. Testes com Docker
Primeiros erros

43. Sai Jenkins e entra Buildbot
Primeiros erros

44. Builds independentes
Primeiros erros

45. Testes ainda demoravam demais
Entre 5-16min
Primeiros erros

46. Primeiros erros

47. https://github.com/grosser/parallel_tests
Testes em paralelo

48. Setup relativamente simples
Testes em paralelo

49. Os tempos eram bons!
Testes em paralelo

50. Primeiros erros

51. Implementação

52. Testes problemáticos falham com
mais frequência
Implementação

53. Auto-retry: Minitest reporter
+ script em Python
Implementação

54. Três categorias de teste:
Pass Danger Fail
Melhoria contínua

55. Usando instâncias spot
Por volta dos USD 300
Custo

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. Em torno de 10h/mês
Operação / Manutenção

58. Como monitorar o CI?
Melhoria contínua

59. Metrics to the rescue!
Melhoria contínua

60. O CI precisa de carinho
Melhoria contínua

61. Conclusão
Solução

62. Aplicações antigas requerem
manutenção constante.
Solução

63. Manutenções incluem refatorar
código ou inclusão de novas
tecnologias.
Solução

64. Suas soluções irão refletir no
futuro, de forma positiva ou
negativa.
Solução

65. Por isso, saiba medir os prós e
contras de cada solução.
Solução

66. Solução
https://weblog.rubyonrails.org/2018/2/17/this-week-in-rails-rails-5-1-5-pa
rallel-testing-and-more/

67. https://github.com/rails/rails/pull/31900

68. $> su ericovis -c 'whereis ${USER}'
Social media: @ericovis
Web: https://emagalha.es
Email: eric@emagalha.es

69. $> su thiago -c 'whereis ${USER}'
Social media: @thiagopradi
Web: https://www.thiagopradi.com
Email: thiago.pradi@gmail.com

70. Wrap up