Scaling Continuous Integration Practices to Teams with Parallel Development
Scaling mobile dev teams
-
Upload
priyank-gupta -
Category
Technology
-
view
329 -
download
1
Transcript of Scaling mobile dev teams
Patterns to scale mobile teamsUsing examples for Android
Priyank GuptaSahaj Software Solutions Pvt. Ltd.
Mobile is eating the world
Evolution in last 5 years
Mobile Inclusive Mobile First Mobile Only
Building it for 3.2 billion people
7.1 Billion - World population
7.9 Billion mobile devices
3.2 Billion Internet Users
State of connectivity 2015 - Report
Mobile users are the internet users
Worldwide market-share
Smartphone market share - Report
Android
iOS
Others
83%14%03%
Everything in ‘context’
Discovery
DeliveryMedia
Payments
Aggregation
Discovering content, deals, products, places and information happens based on location, context and conversations..
Payments, wallets, money transfers and currency conversions happens via mobile apps instantaneously.
News doesn’t come from media houses. News is crowd sourced, crowd curated and pushed real-time to consumers on mobile.
Delivery is done across diverse products and services; ordered, scheduled and tracked via mobile real-time.
Services are aggregated and made available on mobile across all domains. Delivery, taxis, food, handy-work etc.
Why mobile is different?
Challenges
Multiple platforms and
form types
No control on environment /
device
Work across version and device types
Design with usability at center. Stay
ahead of competing feature set
Forced SDK update and
different runtimes
Dalvik, ART, Arm6, Arm7
Survival for fittest
IdeasTons of ideas see daylight in an healthy ecosystem
SaturationRedundant businesses cause saturation to occur
ConsolidationConsolidation in form of acquisition, mergers and natural death.
Healthy co-existenceWinning teams are lean, agile, ahead of competition and know how to scale.
What affects scalability
Things that matter
Hiring & People
Team organization
Technology selection
Development practices
Scalable design
Testing & Safety nets
Release cycle & practices
Technology selection
In business of delivering experience
HTML5
Native
Custom Bridges
Cordova
HTML5+Service workers
React Native
Xamarin
Selecting mobile implementation strategyExperience + Reach
Cost
Laser
Cover your bases
Long term strategy should focus on building a native experience. The journey can be gradual or with a jump start.
No adoption
No magic bullets
Organizing teams for scale
Technology teams vs..
Release 1 - Mix of feature X & Y
Android
iOS
Services
Siloed by technology/platform
If feature parity is important then lowest denominator goes into release
Missed opportunity to optimize services based on common domain across platform
Easier to draw boundaries.
Initial velocity gain due to technical know how.
.. Product team
Release 1 - Feature X
Release 1 - Feature Y
Services iOS Android
Initial velocity impact
Shared understanding of product as a
whole
Feature parity
maintained in releases
Can get away with a leaner
team. Problems
solved once.
Service design can have
considerations for clients
baked in right from start
Handovers & feedback loops
Development
Design
Testing
Story started
Story done
Quicker feedback loops keeps the cost of change low and validates the shared understanding constantly.
Services are part of product
Services
App
Own services as first class
deliverable
Use patterns to decouple
legacy services
Leverage REST Level-3
characteristics to make service
adaptive
Use patterns to optimize services
for target consumer platform
Scaleable dev practices
Predictability & Consistency
Where would you find the code to fetch details from database?
Can you predict how someone on team would fetch images in background?
Will everyone know how to find the service call you wrote?
Can everyone on team predict what’s going to be covered in an espresso test?
Do you know where to find the styling for a specific UI element?
Using conventions you can build predictability on team to simplify mental models needed to understand the codebase
Define the simple machines
Screw Wheel & Axle Pulley Lever
A simple machine can hammer in the basic principle and allow far more complex machines to be developed with coherence.
Adopting patterns
Persistence / db
Web ServicesUI / Styles Debugging
Invest time in first of everything. Build a team-wide definition and reuse the pattern to promote consistency and predictability.
Background tasks / Services
Device hardware
Web service patterns
for consistent service calls across features. Retrofit + Singletons + Observers
Callback implementation for Retrofit API (Singleton)
Retrofit service interface
Observers
Activities, fragments or services
Data retrieved from service (possibly cached)
External integrations patterns
BFF approach | Adaptive API
Adaptive API
Backend for frontend
Downstream systems
Adaptive proxy APIs
Consumer centric abstractions - BFFs
for optimal experience of services on devicesAdaptive APIs BFFsor
for consistent execution of short async tasksAsync task wrapper + Observers Thread (Pools)or
Asynchronous tasks patterns
Obtain instance
Set data
Fire task
Check references
Call observers
Die or loop
Main thread
Spawned/Pooled thread
Scaling commits with patterns
Feature one
Feature two
Master
Feature toggles explained
vs
Requires complex CI setup to constantly identify and merge branches and test state at any point of time.
Requires building a feature toggle functionality with dynamic toggles and tests to validate all feasible path.
Master
Feature onetoggled off
Feature twotoggled off Feature two
toggled on
Feature onetoggled on
Debugging and logging patterns
Force upgrade Debug console Thread local logging
Crashlytics
Build consistent set of practices to debug issues using Debug console Crashlytics Thread logging
Building reliable safety nets
TDD - Achieving 80-85% coverage
1
2
3
4
5
6
With domain logic extraction
Dependency injection with constructors
Mock objects using mockito
Powermock + Mockito for static classes **
Countdown latches & listeners for threads
Presenter pattern to extract view logic
Building the most comprehensive set of tests at unit level
Behavior tests with page object pattern
pattern comes in handy to modularize behavior tests and mimic flow relationshipsPage Object
Home screen
Product listing
Notifications
Orders
Execution context
Asserting app behavior
Service Stubs
Real Service
APIs
can be used to address the coverage gap left by unit tests in AndroidEspresso
WireMock Mountebank Stubby
Making behavior tests effective
Turn on ‘don't keep activities in
background’
Among all others, run the
smallest supported
emulator with software keyboard
Immediate app
distribution to alpha. Hallway testing
Multiple emulators in cloud or via
Docker images across CI agents
Keep behavior tests lean, quick and focused on happy path
Testing the service contract
Actual Service/APIsContract
Tests
Service Stubs
Contract tests run typically few times a day. A stub replaces remote service for behavior tests to keep tests responsive, stable and predictable.
Every commit
Periodically
Testing cross app flows
is a great starting place to orchestrate tests across apps
Uber engineering blog
Octopus by Uber
Consumer app
Warehouse app
Consumer on iOSOrchestrator
Thanks for pulling through!
priyaaank