The more devs the merrier? (Part 1)
To meet the needs of a higher quality application, higher traffic and new features, Blablacar’s Android Team had to grow fast!
Scaling from 2 devs to 10 and soon 20 in a few months isn’t straightforward: sharing the same codebase, code reviews, release process, architecture shift, managing different personalities… When you grow fast like a teenager, there are lots of questions, lots of failures, and lots of lessons — and we’re going to share them with you.
(Written in collaboration with Thomas Salandre)
TL;DR;
When your team is growing fast you have to invest on those points:
- Transform to an appropriate architecture: Modularization + Clean architecture allow to work with a larger team on the same code base
- Improve your Review and Test process to be able to push safely more code in production
- Define clear coding and architecture rules to align everybody very quickly on a coding process and vision. Iterate on it.
- Increase the level of dialog and sharing inside the team. Work hard on the communication and onboarding process.
1 — The application context
BlaBlaCar is the world’s leading carpooling service. Its purpose is to connect drivers and passengers doing the same trip to fill up empty seats.
At the beginning of 2019, the company’s strategy started to shift. Being the world leader in carpooling service for years, the ambition grew, and the service started to change from a carpooling service to a shared mobility service, adding busses, and possibly other means of transport in the future.
This shift was big in terms of ambition, and meant we needed to grow our frontend teams quickly to respond to the technical challenges ahead. At the beginning of the period, the Android team was composed of 3 people, including one manager. The goal was to reach 10 developers by the end of 2019. We’ll see later why we chose this number, and what it meant in terms of organization.
Let's see the other changes we made on the technical part, organization and processes to scale our team and meet our objectives.
2 — Technical changes put in place
Architecture change
To be able to grow the team, we had to change the architecture of the codebase and define clear architecture rules. The application architecture was getting old and MVP wasn’t fitting our needs anymore. Created in July 2013, the application had more than 40 contributors since then and contained a lot of classes, screens, spaghetti code and legacy.
One of the main goals of the new architecture was to add modularity to the application to be able to work in parallel on the app without impacting each other’s developments.
We also wanted our code to respect the SOLID principles to be easily testable, to be responsibility limited, and to limit the impact of low component and API changes.
We found in the Clean Architecture an architecture able to fit all our requirements. It is composed of these three components:
- Presentation
- Domain
- Data
We use mappers to convert the models between each layer, to avoid any impact when a change happens on a layer. The Domain module is the most isolated and doesn’t know anything about the other modules nor the environment it’s running on.
Presentation
- The presentation module will contain your activities/fragments and your presenter. Mappers will be used to convert Entities (Models from the Domain module) to UIModels used for your presentation.
Domain
- The domain package is responsible for handling pure Business Logic and defining Entities representing your business models while exposing interfaces that will be implemented by your app Services.
Data
- The Data modules will implement the interfaces defined in the Domain layer to provide data to our Interactor. These interfaces implementations are called Repositories and use DataSources to fetch data.
This architecture change really helped us meet our goals. We now have a well testable app, with single responsibility components, allowing us to work in parallel on the same features.
Testing and Quality strategy
The BlaBlaCar application is used by hundreds of thousands of users each day. It’s exciting to work on an application with such traffic, but each mistake can be very costly, and each change can lead to thousands of users having an application crashing. With the growing number of developers, we had to scale our app testing to be able to maintain the application quality while having way more changes and features developed.
We, therefore, needed to have a well-defined test strategy throughout our development process. From unit tests before merging a feature branch, to QA Team tests and war rooms before submission, we defined a lot of steps to ensure the application quality :
Unit tests and Reviews
- The first step that comes into play is the creation and update of unit tests. The clean architecture allows us to Unit Test almost every component of our application. The BlaBlaCar Android app now contains more than 3000 unit tests.
QA Tests
- We are lucky enough to have an incredible QA team at BlaBlaCar. The goal of this team is to ensure the quality and stability of all the frontend apps in the company by creating a set of integration tests compatible with all mobile apps. Those tests are running continuously, testing all the important features of our application.
Warrooms
- Despite the QA tests, some of our features are very hard to reproduce and tests in an automatic way. By manually testing the remaining features before each release during a common meeting between the Android and QA teams, we make sure that none of these features have been broken.
Rollout
- To ensure that our changes don’t have a bad impact or bugs, we first send our update to a company internal beta channel. Once it’s done, we take advantage of the progressive rollout feature of the Play Store and send our app update to 20% of our users, then increase this rollout to 50% then 100% every 24 hours.
This Quality strategy has been very successful for us, and we are proud to have a crash-free user rate of 99.9%.
