Avito Mobile: State of the Union

Размер имеет значение. Это верно и для приложения Авито, которое разрабатывается сразу несколькими десятками независимых кроссфункциональных команд, в каждой из которых есть по несколько iOS разработчиков. За последние пару лет мы столкнулись с различными проблемами масштаба, часть из которых получилось успешно решить. В докладе я поделюсь техниками и советами, которые позволяют нам удерживать качество продукта на высоком уровне и стабильно релизиться раз в 2 недели, одновременно с этим предоставляя максимальную свободу разработчикам в выборе архитектуры и пути решения их проблем.

Transcript

1. Avito Mobile
 State of the Union INSERT COIN TO CONTINUE
2. PAGE 02/51
3. PAGE 03/51 Backend Mobile Frontend Product Designer QA
4. PAGE 04/51 Unit Seller Unit Mnz
5. PAGE 05/51 Unit Seller Make sellers happy +15% items -34s create item
6. PAGE 06/51 Unit Mnz Make more money +40% $ from vas
 +35% $ from ads
7. PAGE 07/51 Mnz Seller Buyer Billing Growth
8. PAGE 08/51 > Stop the release, I'm finishing a feature > I don't want to use VIPER > App start up time is not my problem
9. PAGE 09/51 Product units > Work for end users Platform units > Work for product teams
10. > Releases > Architecture > Performance PAGE 10/51
11. PAGE 11/51 > Releases > Architecture > Performance
12. PAGE 12/51 ft.A Unit 1 Unit 2 Unit 3 Release 1 ft.C ft.D ft.E
13. PAGE 13/51 ft.A ft.C ft.D ft.E Unit 1 Unit 2 Unit 3 Unit 3 Unit 1 Unit 2 Unit 3 Release 1 ft.B ft.F ft.G ft.H Release 2 ftI
14. PAGE 14/51
15. PAGE 15/51 feature freeze 1st regress end 2nd regress end staging release > Release cycle
16. PAGE 16/51 Criteria: 1. Closed in Jira 2. Tested 3. Has feature toggle > ... - feature freeze
17. PAGE 17/51 Automation: 1. Git+Jira 2. Feature Toggle config 3. Slack mentions 4. Branch cut > ... - feature freeze
18. PAGE 18/51 > feature freeze - 1st regress end Unit tests Component tests E2E tests Manual tests 1. Regression test suite is run 2. Each unit performs impact analysis 3. Each unit manually tests its features 4. P0/P1 bugs are fixed or features are disabled
19. PAGE 19/51 > 1st regress end - 2nd regress end Unit tests Component tests E2E tests Manual tests 1. Regression test suite is run 2. Impact analysis for fixed bugs 3. Broken features are disabled
20. PAGE 20/51 > 2nd regress end - staging 1.Roll out for 1% users 2.Automatically watch for crashes & metrics 3.Hotfix if necessary
21. PAGE 21/51 > staging - release 1.Manual roll out 2.Anomaly detection 3.Hotfix if P0 bug
22. PAGE 22/51 > Release cycle 1. Release automation 2. CI/CD hacks 3. Tooling
23. PAGE 23/51 30 200 700 860 Q1 Q2 Q3 now > E2E Testing Began automatisation in Q4'2017 Currently 860 UI test methods 3 devices 2610 tests in regress suite
24. PAGE 24/51 Our tooling - XCUITest - Wrapper (MixBox) - Test runner (Emcee) > E2E Testing
25. PAGE 25/51 Who write tests - Manual QA - Engineers > E2E Testing 65%
 QA 35%
 engs
26. PAGE 26/51 1. Why XCUITest 2. Millions of hacks 3. MixBox > E2E Testing
27. PAGE 27/51 1. Infrastructure 2. Running tests in parallel 3. Simulators > E2E Testing
28. PAGE 28/51 > Releases > Architecture > Performance
29. PAGE 29/51 > Tragedy of Commons
30. PAGE 30/51 > Monolithic Architecture Problems - Build time - Responsibility scopes - Impact analysis
31. PAGE 31/51 > Modular Architecture
32. PAGE 32/51 > Modular Architecture Core layer - Networking - Routing - Deeplinking - Persistance - Logging - etc
33. PAGE 33/51 > Modular Architecture module 1 module 2 module 3 module 4
34. PAGE 34/51 > Modular Architecture Feature consists of - Code modules - UI - Network requests - Persistance requests - Models - Navigation
35. PAGE 35/51 > Modular Architecture
36. PAGE 36/51 > Modular Architecture Mediator layer - Module interfaces - Service interfaces - Models
37. PAGE 37/51 > Modular Architecture Metrics - 150 modules - 9 months for transition - Clean build: 635 -> 438s - Incremental build: 65 -> 15s
38. PAGE 38/51 > Modular Architecture How we use it - Each module has its owner - Demo apps out of the box - Module lazy load - Module quality checks: usage, contributors, build time, etc
39. PAGE 39/51 1. Architecture details 2. Transition process 3. Experiments 4. Usage > Modular Architecture evgeniy suvorov
40. PAGE 40/51 > Releases > Architecture > Performance
41. PAGE 41/51 App performance affects business metrics. > Hypothesis
42. PAGE 42/51 5% of daily audience, each group - 1% - A,B - control groups - C - +2s delay - D - +4s delay - E - +6s delay > Experiments
43. PAGE 43/51 1. Performance affects bounce rate 2. Hygienic minimum - 4s 3. Most problems in regions 4. [Web] 1s of speed up -> 0,2-4% business metrics > Results
44. PAGE 44/51 > Avito - daily use service Our target: - Cold start - 1,5s - Screen first paint - 0,1s - Screen first interactive - 0,5s - Scrolling - 60fps
45. PAGE 45/51 > Performance Monitoring Culture Optimisations
46. PAGE 46/51 > Optimisations 1. Modules lazy loading 2. Network optimisations 3. Lazy DI 4. Lazy tabs creation 5. DI without reflection
47. PAGE 47/51 > Monitoring
48. PAGE 48/51 > Monitoring init load parse draw
49. PAGE 49/51 > Culture 1. Internal meetups 2. Competitors dashboards 3. All screens dashboards 4. Success stories 5. Trending
50. > Releases > Architecture > Performance PAGE 50/51
51. Egor Tolstoy > Avito Mobile many features many developers many challenges Avito t.me/etolstoy