Behind the scenes tour to the full rewrite of three high street mobile banking apps

Lloyds Banking Group has 3 high street mobile banking apps (Bank of Scotland, Halifax and Lloyds) with 10M+ customers over UK.

By the end of 2016, the mobile banking app codebase become so expensive to maintain, so hard to add new features, so difficult to work with that a team of adventurous engineers recommended a full and total rewrite.

The management supported the idea and allocated funds for the initiative and the Mobile 3.0 project was born.

During this lightning talk Miklos will share with you the key lessons learned during the project, gives insight to the struggles and achievements of such an ambitious project which delivered the next generation apps of the Group. You will also learn about the engineering transformation of mobile app development happened in Lloyds.

Transcript

1. MOBILE 3.0 BEHIND THE SCENES TOUR TO THE FULL REWRITE OF THREE HIGH STREET MOBILE BANKING APPS @SagiMiklos
2. Miklos Sagi Engineering Lead for Android & Quality Engineering Digital Platform Evolution Theme Lloyds Banking Group @SagiMiklos
3. WHY? !3
4. WHAT? !4
5. OBJECTIVE Build the new client platform Scalable, iterative delivery Re-invent the way of working Engineering transformation WHAT IS MOBILE 3.0? !5 TEAM MIX 30 Android Engineers 30 +5(TiB!) iOS Engineers 45 QE APPLICATION REWRITE EXERCISE Clean Architecture Pattern Android: Java into Java & Kotlin iOS: ObjC into Swift
6. Objective • Build a strong and motivated mobile engineering team Made a difference: Raised the bar for recruitment • 3 layered technical interview (Java + Android + Whiteboard Coding) • Hiring the top 20% • Check out this article Android Connect • Build engineering culture (algorithmic challenges, coding contest, tech demos) • Share information within a large team #1: PEOPLE
7. Objective • Raise the code quality of the Apps by setting up automated quality checks, test, train the engineers and define processes of the day to day work
 Made a difference: Feature Configuration • Daily, small, iterative changes to a single master branch • Features are added ‘behind’ Feature Configuration (release trains! e.g. unfinished features are enabled for test, disabled for production) • Scalable, iterative development Integrated code review automation (Gerrit!) • The automation connects the change owner with 2 reviewers via an IM channel • The automation pings the change owner or the reviewer when their interaction is needed • This instant communication has increased our daily merges by 20%! #2:CODE QUALITY
8. Objective • Use a flexible, modular, enterprise app ready architecture Made a difference: Clean architecture • Architecture is very important for large team (flexibility, easy to understand and follow, testability) Multiple Apps from one code base • All 3x mobile banking apps are built from a single source • Modular for faster build • Easier to add new features, quicker to fix bugs • Safer release process #3: APP ARCHITECTURE
9. Objective • Automate our build toolchain and build our automated functional testing suite to save costs and speed up our delivery Made a difference: Regular review of the build scripts • Update our build tools to latest available • Break big dependencies to multiple smaller ones • Review bottlenecks and smash them • E.g. just by upgrading Gradle and eliminating some bottlenecks in the build scripts we managed to make the full build time 2x faster and the local build time 5x to 50x faster! #4: CONTINUOUS INTEGRATION / DELIVERY
10. Objective • Shift testing left • Automate our regression and compatibility testing Made a difference: Hybrid AFT • Native test set (Espresso / XCUITest) (on feature branch) • Appium / JS based test set (on master) • In-cloud device grid • PoC: On-site device grid (No network latency) • PoC: Local device grid (Ad-hoc config) #5: TEST AUTOMATION
11. #6: RELEASE PROCESS Objective • Release 3 Apps (Bank of Scotland, Halifax and Lloyds mobile banking Apps) quickly and frequently with low risk of incidents Made a difference: Release quickly but not risky • The App architecture is designed in a way that the 3 mobile banking Apps has the same code (this makes bug fixing significantly faster). • The release starts with the App of the smallest user base. • Staged roll-out while getting metrics and feedback at scale • Fix the top issues continuously • When the next iteration is ready (with bug fixes), swap the actual % with the next iteration, track the issue rate drop, then continue scale out until 100%
12. THE KEY INGREDIENTS PEOPLE CODE QUALITY CI / CD RELEASE APP ARCH AFT
13. THE CHALLENGES It is hard to prepare for these:
 • Xiaomi Apache Commons library preload • Android Studio cannot refactor in between source sets / build variants • 1* reviews due to not supporting rooted devices • Gradle could not handle our 14k+ mock files • Switched app launcher icon from drawable to mipmap • Customer learning Italian
14. TO 5 STAR REVIEWS The new mobile banking apps have been rolled out to our customers
15. TO 5 STAR REVIEWS !15 We have been through a long journey and mobile App development within Lloyds has been transformed. We continue this journey and keep focusing on the key ingredients: • To improve our customer experience for the Apps in the App stores • And to improve our engineers’ life with Lloyds Banking Group
16. We are hiring! @SagiMiklos
17. THANK YOU! We are hiring! @SagiMiklos
18. RESOURCES Lloyds Banking Group • Job Portal (We are hiring!) • Twitter: @LBGDigi • LinkedIn: Lloyds Banking Group Miklos Sagi • Twitter: @SagiMiklos • LinkedIn: Miklos Sagi • Medium: @miklos.sagi • How to build an awesome Engineering Team? • How to transform before driving transformation? IBM • IBM Cloud: a rich platform for innovation • IBM Startup Program • IBM Developer Portal