Breaking the monolith @ Booking.com

Transcript

1. Breaking The Monolith @ Ishan Khanna @droidchef 1
2. What I will not talk about 2
3. What I will talk about 3
4. Rewind back to early 2017... 4
5. Clean Builds ~ upto 12 minutes 5
6. Incremental Builds ~ up to 2 minutes 6
7. Number of features ∝ Build Time 7
8. Attempt #1 : Instant Run 8
9. It didn’t work! 9
10. Attempt #2: Breaking the Build... 10
11. Attempt #2: Breaking the Build into Variants 11
12. So we blew a KISS to Gradle 12
13. Product flavors on diet 13 // SDK versions minSdk = propOrDef('MIN_SDK', "21") // ResConfigs language = project.hasProperty('RES_LANGUAGES') ? project.RES_LANGUAGES : (project.hasProperty('RES_RTL') ? "ar" : "en") density = project.hasProperty('RES_DENSITY') ? project.RES_DENSITY : "xhdpi"
14. KISS = Keep It Simple Silly 14
15. It worked, but you know, how devs are! 15
16. Attempt #3: Composite Builds 16
17. 17 BookingAndroid Assistant B.Commons Analytics Project structure setup
18. How did it work? compile 'booking.libraries.commons' 18
19. Excited to the see results? 19
21. It didn’t work! 21 • Gradle config time increase • Clean build time for each module increased by 30 seconds • Incremental build time for each module increased by 10 seconds
22. Attempt #4: JRebel 22
23. We got mixed feelings about it! 23
24. But, it didn’t work! 24
25. Attempt #5: Modularization 25
26. - Breaking down application into separate modules - Imagine microservices - Concept dates back to 1960s What? 26
27. - One entry point for each module - One exit point for each module - Establish navigation between screens / areas of screens ( modules) How? 27
28. - Productivity: - Modules also faster development - Quicker iterations - Smaller build times - Build times can be as low as ~10-20 seconds for smaller modules - New Features: - Ability to replace & easily introduce new modules - Feature X, Feature Y - Tech debt: - More isolated code - Open possibility of code reuse - Minimize maintenance cost Why? 28
29. Layers Current structure: - presentation Anything that contains at least 1 full screen. (bookingGo, BP, feature, etc.) - appServices Any logic that should/can be shared between presentation layers. (common UI components, horizontal teams, dataModels, etc.) - coreServices Basics. Things that can be considered to reused in other apps (analytics, localization, network, iconFont) 29
30. Android Foundation commonUI search dataModels User Profile currency db price images assistant bookingGo System Core services modules App services modules Presentation modules commons iconfont crashlytics analytics reservation Interface Quality library, localization Core libraries: networking, analytics, etc. network service A Foundations service B A brief overview of our modules service C UGC data UGC components Genius components survey 30 service D service E
31. Reusing modules in multiple screens UGC App services modules Presentation modules UGC data UGC components Screen 3 Screen 2 Screen 1 31
32. Current tools: utils/create_module.sh: helper script to create modules with basic dependencies, supporting translations (if needed) utils/findbugs-generate-baseline.sh: helper script to generate findbugs baseline for particular module Android dependency visualizer: https://github.com/alexzaitsev/apk-dependency-graph Tools, to simplify the work... 32
33. 33 Solving the Funnel Problem for Developers Search Search Results .... Reservation • Make a search • Select a result • Pick a room • Fill in some info and make a reservation...
34. AppStart tests • Deep Link into a module • Real / mocked data • Different set of data for different use-cases 34
35. 35 @Test public void launchResults() { initializeBookingGoWithoutFakeBookings(false); startResultsScreen(); sleepD(DAYS.toMillis(1)); }
36. Android Foundation commonUI reservation broadcast dataModels User Profile currency db price images assistant bookingGo debugFeatures search System Core services modules App services modules Presentation modules commons iconfont crashlytics analytics Service A Module ABC IQ library + localization Core library: networking, squeaks, ET, etc. network GA Debug Booking foundations collections functions Your module doesn’t depend on it - no need to build Your module doesn’t depend on it - no need to build Build just your dependencies BookingGo 36
37. Example: • 11 app start tests • Opens specific parts of the app ◦ Start screen ◦ Results screen ◦ Booking summary ◦ ... • Tests with real or fake/mocked data 37
38. Examples: BookingGo.mockedBookingSummary 38
39. Examples: Payments 39
40. Examples: Payments 40
41. Examples: Payments Normal start Start Test Code change in module ~25 seconds ~12 seconds Resource change in module ~28 seconds ~13 seconds Change in main module ~40 seconds 41
42. But seriously what are advantages for you... - much faster development times - easier to spot problems when you have 10-100 files instead of 10000…. - Have your own SLAs: X lint warnings, unit tests coverage, UI tests coverage... 42
43. How can you do it? 1. Modularize 2. Have fake / real activity 3. Create an AppStartTest 4. Make tests depending on the types of features you work on. 43
44. Thank you! All references to “Booking.com", including any mention of “us”, “we” and “our” refer to Booking.com BV, the company behind Booking.com™ 44