Presentation in TDC São Paulo 2018

1. Builds incrivelmente
rápidos com BUCK
Leandro Borges Ferreira - Software Engineer @ Nubank
Thales Machado - Software Engineer @ Nubank
no Nubank

2. Platéia - Vamos participar?
Alguém aqui…
- Acha que o app Android “builda" rápido?
- Acha que dá pra rodar os testes de UI na própria máquina?
- Já passou alguns dias gastando mais tempo debugando
gradle/test flaky/tentando fazer CI passar…
- Nunca teve que dar “./gradlew clean” pra consertar um
problema de build?

3. Nosso app cresceu…
+/- 1k de UI
Milhares de testes unitários
+/- 10 devs de cada plataform
+/- 20 devs de RN

4. App no início de 2017
- 40~50 min clean build no CI
- ~1h UI tests
- 5~6 min de unit + (rebuild) ~15min (único flavor)
- +- 2h cada run do CI
- Um único projeto

5. App no início de 2017

6. Divisão por lógica de negócios
• Cada squad é empoderado a ter sua
própria parte do app
• Priorização decentralizada
• Código desacoplado
• Spikes de novas tecnologias
• Sem dor de projeto grande

7. Como?
• Funcionalidades comuns numa
biblioteca própria
• Começar um novo projeto por uma
template

8. Common Libraries
Nubank Android Core

9. Common Libraries
Nubank Android Core

10. Common Libraries
Nubank Android Core

11. Common Libraries
Nubank Android Core

12. Common Libraries
Nubank Android Core

13. Common Libraries
Nubank Android Core

14. Common Libraries
Nubank Android Core

15. Common Libraries
Nubank Android Core

16. Schemata
Managers
CoreAnalyticsblocks ui
http
Common Libraries
Nubank Android Core
Help BonafontNuConta Feed
. . .. . .
O que ganhamos?
• Build rápidos - Ao separar cada um em seu
repositório
• Test suits menores
• Felicidade 😁
• Documentação e arquitetura concisa
dentro de um projeto

17. Schemata
Managers
CoreAnalyticsblocks ui
http
Common Libraries
Nubank Android Core
Help BonafontNuConta Feed
. . .. . .

18. Schemata
Managers
CoreAnalyticsblocks ui
http
Common Libraries
Nubank Android Core
Help BonafontNuConta Feed
. . .. . .

19. Common Libraries
Nubank Android Core
Schemata
Managers
CoreAnalyticsblocks ui
http
Help BonafontNuConta Feed
. . .. . .
android-app
Downsides
• Mudanças em diversos projetos virou doloroso
• Comunicação cross-squad sobre as mudanças
• Nem todo mundo trabalhando em projeto
novo (build do antigo lento)

20. Common Libraries
Nubank Android Core
Schemata
Managers
CoreAnalyticsblocks ui
http
Help BonafontNuConta Feed
. . .. . .
android-app
foundation

21. Common Libraries
Nubank Android Core
Help BonafontNuConta Feed
. . .. . .
android-app
foundation

22. Common Libraries
Nubank Android Core
Help BonafontNuConta Feed
. . .
foundation
blankets react-native-common-bridge
All JS
dependencies
Anticipation
react-native-central
. . .
android-app

23. O que fizemos??

24. Monorepo
Juntar todos os projetos de novo em
um único só

25. Arquitetura do projeto

26. Mas e o tempo de build, teste e tudo mais????
Monorepo

27. Nós vivemos no futuro
- Múltiplos Cores
- SSDs
- Muito muito RAM
- Storage é barato
- Trafego da dados é rapido
- Distributed Version Controls Systems

28. Mas nossas ferramentas vivem no passado!
- Baseado em “Tasks"
- Muito mágico
- Difícil de paralelizar

29. O que seria o ideal?
- Conseguir buildar partes pequenas do projeto separadamente
- Grafo de dependencias explicito -> Paralelização
- Rebuildar somente o necessário

30. Arquivo de configuração por package/diretório
- Fácil de compartilhar, buscar e reutilizar código
- Menos boilerplate

31. Build Rules
- Módulo tem conhecimento do que e como buildar
- Dependencias declaradas explicitamente

32. Directed Aciclic Graph
- Dagger de novo?
- Grafo -> Paralelismo
A B C
D
F

33. Cache!
- O rebuild não deveria ser mais rápido?
- Tanto local como distribuído 👀 👀 👀

34. Buck
- Open source
- Apache 2
- https://github.com/facebook/buck

35. Buck
Pensado para mono repositórios
Projetos devem ser modulares
Cache bastante agressivo
Grande ganho de performance

36. Tipo isso aqui

37. Buck - Alguns aprendizados
Vale a pena para apps modulares
Kotlin (e Swift) não é ABI estable =|
Builds mais reproduzíveis (e menos mágicos)
Kotlin support ainda é bebe
Você vai querer usar o okBuck

38. Dados Buck
Build Dep3
clean build sample staging
gradle -> `BUILD SUCCESSFUL in 3m 13s`
buck -> `Building: finished in 01:55.7 min`
Mudanças em Dep3
gradle `BUILD SUCCESSFUL in 22s`
buck -> `Building: finished in 16.4 sec`
Mudanças em Dep2
gradle -> `BUILD SUCCESSFUL in 30s`
buck -> `Building: finished in 16.3 sec`
(it only needed to recompile dep2 itself and the
sample dexing and packaging stuff)
Mudanças em Dep1
gradle -> `BUILD SUCCESSFUL in 45s`
buck -> `Building: finished in 15.2 sec` (it only
needed to recompile dep1 itself and the sample
dexing and packaging stuff)
Dep1
Dep2
Dep3

39. Tá, mas na prática...

40. Ao todo são 1k de testes…
Só que separados em várias pipelines

41. Não dá para “só mudar” o
processo atual

42. Problemas a resolver
Pipelines longas, flakness é um problema
Mais caro rodar nossos testes
É necessário um momento de transição
Buck nem tinha suporte a Kotlin

43. Device farm in house

47. Build Testes - Todos Testes - Falhas Deploy
S3

48. Mono repo
dependencies.gradle
build.gradle
dependencies.gradle
build.gradle
dependencies.gradle
build.gradle
dependencies.gradle
build.gradle
dependencies.gradle
build.gradle

49. Git meta
Comandos em loop
Mesma estrutura do git
ex: meta git branch

50. Difícil de mudar o processo atual
PRs em dois repositórios
Processo não pode ser gradual
Tabela da verdade está no gradle
Meta git é meio chato de usar

51. Mudança final
Mudança difícil para criar mono repo mantendo históricos
PRs devem ser congelados
Não tem volta 😱

52. Ficou bem mais fácil fazer breaking changes

53. O build realmente é bem mais rápido
Android-app gradle: 4 minutos
Todas as dependências Buck: 2,5 minutos

54. Testes unitários paralelizados “de graça”

55. Aprendemos muito

56. Obrigado