Slide 1
Slide 1 text
Breaking The Monolith @
Ishan Khanna
@droidchef
1
Slide 2
Slide 2 text
What I will not talk about
2
Slide 3
Slide 3 text
What I will talk about
3
Slide 4
Slide 4 text
Rewind back to early 2017...
4
Slide 5
Slide 5 text
Clean Builds ~ upto 12 minutes
5
Slide 6
Slide 6 text
Incremental Builds ~ up to 2 minutes
6
Slide 7
Slide 7 text
Number of features ∝ Build Time
7
Slide 8
Slide 8 text
Attempt #1 : Instant Run
8
Slide 9
Slide 9 text
It didn’t work!
9
Slide 10
Slide 10 text
Attempt #2: Breaking the Build...
10
Slide 11
Slide 11 text
Attempt #2: Breaking the Build into Variants
11
Slide 12
Slide 12 text
So we blew a KISS to Gradle
12
Slide 13
Slide 13 text
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"
Slide 14
Slide 14 text
KISS = Keep It Simple Silly
14
Slide 15
Slide 15 text
It worked, but you know,
how devs are!
15
Slide 16
Slide 16 text
Attempt #3: Composite Builds
16
Slide 17
Slide 17 text
17
BookingAndroid
Assistant
B.Commons
Analytics
Project structure setup
Slide 18
Slide 18 text
How did it work?
compile 'booking.libraries.commons'
18
Slide 19
Slide 19 text
Excited to the see results?
19
Slide 20
Slide 20 text
20
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
Attempt #4: JRebel
22
Slide 23
Slide 23 text
We got mixed feelings about it!
23
Slide 24
Slide 24 text
But, it didn’t work!
24
Slide 25
Slide 25 text
Attempt #5: Modularization
25
Slide 26
Slide 26 text
- Breaking down application into separate modules
- Imagine microservices
- Concept dates back to 1960s
What?
26
Slide 27
Slide 27 text
- One entry point for each module
- One exit point for each module
- Establish navigation between screens / areas of screens ( modules)
How?
27
Slide 28
Slide 28 text
- 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
Slide 29
Slide 29 text
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
Slide 30
Slide 30 text
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
Slide 31
Slide 31 text
Reusing modules in multiple screens
UGC
App services
modules
Presentation
modules
UGC data
UGC
components
Screen 3
Screen 2
Screen 1
31
Slide 32
Slide 32 text
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
Slide 33
Slide 33 text
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...
Slide 34
Slide 34 text
AppStart tests
● Deep Link into a module
● Real / mocked data
● Different set of data for different use-cases
34
Slide 35
Slide 35 text
35
@Test
public void launchResults() {
initializeBookingGoWithoutFakeBookings(false);
startResultsScreen();
sleepD(DAYS.toMillis(1));
}
Slide 36
Slide 36 text
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
Slide 37
Slide 37 text
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
Slide 38
Slide 38 text
Examples:
BookingGo.mockedBookingSummary
38
Slide 39
Slide 39 text
Examples: Payments
39
Slide 40
Slide 40 text
Examples: Payments
40
Slide 41
Slide 41 text
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
Slide 42
Slide 42 text
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
Slide 43
Slide 43 text
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
Slide 44
Slide 44 text
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