Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A guide through publishing white label apps in a healthy way

Stefan M.
November 10, 2022

A guide through publishing white label apps in a healthy way

Given at Mobile DevOps Summit 2022

Publishing and releasing one Android app is easy.

But what if you have to publish 5 apps, or 10, or even 50?

You have to start thinking about the build time on your continuous delivery server to build all of those apps. You have to think about how to roll them out in a comfortable way. You have to think about your architecture and a lot more...

We are at ioki creating white label apps and have, as of today, 38 apps public in the Play Store.

In this talk, I will guide you through the challenges we had to publish more and more apps over the years in a healthy way. I will show you what we did - release process-wise as well as code architecture-wise - to scale further to stay in this healthy environment we have today.

Takeaways from this session:
1. A reliable continues delivery server is important
2. Architecture is important when you publish multiple apps
3. What does it mean to growth in a healthy way

Stefan M.

November 10, 2022
Tweet

More Decks by Stefan M.

Other Decks in Technology

Transcript

  1. A guide through
    publishing white label
    apps in a healthy way

    View Slide

  2. This is me
    ● Stefan May
    ● Live in Germany
    ● Android Development since 2014
    ● Senior Android Developer @ioki since 2020
    StefMa.medium.com
    twitter.com/@StefMa91
    github.com/StefMa

    View Slide

  3. This is ioki
    ● Founded in 2017
    ● Subsidiary of Deutsche Bahn
    ● Complements existing public transport with an demand responsive transport (DRT) system
    ● Providing an platform to customers to enabling them to provide a DRT service
    ○ SaaS
    ○ Consulting
    ○ APIs
    ○ White Label Apps (WLA)

    View Slide

  4. View Slide

  5. … and counting

    View Slide

  6. ● 2017, 1 app “ioki” (test balloon)
    ● Setup “default” release process
    ○ Bitrise as CI/CD
    ○ Automated releases via an Gradle plugin
    ● Releasing at end of sprint (each two weeks)
    ○ Release officer, changing responsibility in the Android team (3/4 people)
    ● Bitrise -> CreateRelease Workflow
    ○ Version name
    ○ Version code (will be calculated)
    ○ Bitrise fetch `main` branch, lint + test, build and release to Play Store (internal track)
    ○ Manual testing of this app (Head of Mobile)
    ○ Test succeeded, release office go to Play Store and move app to production (and alpha) track
    Where it starts

    View Slide

  7. This process is good

    View Slide

  8. This process is good
    … as long you have only one app

    View Slide

  9. ● Decision: We do white label apps
    ● Code: build flavors
    ○ Small flag within the app to create “a clone” of the app to create multiple apps
    ioki entered the WLA market

    View Slide

  10. Other stuff weren’t touched

    View Slide

  11. But we grew…
    and created one white label app after the other…

    View Slide

  12. ● Increasing build time
    ○ The build tool (Gradle) has “to do” something for each app
    ● Developer productivity (DP) suffers
    ○ Time from “start build” to “deployed on device” increased
    ○ “What do I wanted to test”?
    ○ “Why did I even wanted to deploy the app on the device”?
    ○ “Ahhh, I found a mistake. Let me quickly change this and build again”!
    The first problems

    View Slide

  13. ● Increasing build time
    ○ The build tool (Gradle) has “to do” something for each app
    ● Developer productivity (DP) suffers
    ○ Time from “start build” to “deployed on device”
    ○ “What do I wanted to test”?
    ○ “Why did I even wanted to deploy the app on the device”?
    ○ “Ahhh, I found a mistake. Let me quickly change this and build again”
    ● Solution:
    Build flavor filter
    The first problems

    View Slide

  14. ● Flavor were defined in the application module (Gradle project)
    ➡ All other library modules (Gradle projects) had access to flavors
    A similar, but other problem

    View Slide

  15. ● Flavor were defined in the application module (Gradle project)
    ➡ All other library modules (Gradle projects) had access to flavors
    ● (Interim-) Solution:
    Flavors as a library module, only applied by the application module
    A similar, but other problem

    View Slide

  16. Who wants to be the release officer?

    View Slide

  17. ● Remember our publishing process?
    ➡ Manually moving the apps from the internal track to the production (and alpha!) track
    Please do the release, officer!

    View Slide

  18. 1. Open Play Store
    2. Open an App
    3. Go to Release Management -> App releases
    4. Choose the track that should be updated
    5. Click Create Release
    6. Choose an APK from the Artifact Library and pick the latest one
    7. For release notes, choose Copy from previous release and choose the latest from the current track
    8. Click Save then Review
    9. Set rollout rate to 30% for the initial publishing
    10. Hit Rollout!
    The publishing process for a single app

    View Slide

  19. 1. Open Play Store
    2. Open an App
    3. Go to Release Management -> App releases
    4. Choose the track that should be updated
    5. Click Create Release
    6. Choose an APK from the Artifact Library and pick the latest one
    7. For release notes, choose Copy from previous release and choose the latest from the current track
    8. Click Save then Review
    9. Set rollout rate to 30% for the initial publishing
    10. Hit Rollout!
    11. Repeat for other Tracks and Apps
    I don’t want to live on this planet anymore

    View Slide

  20. 1. Open Play Store
    2. Open an App
    3. Go to Release Management -> App releases
    4. Choose the track that should be updated
    5. Click Create Release
    6. Choose an APK from the Artifact Library and pick the latest one
    7. For release notes, choose Copy from previous release and choose the latest from the current track
    8. Click Save then Review
    9. Set rollout rate to 30% for the initial publishing
    10. Hit Rollout!
    11. Repeat for other Tracks and Apps
    Then fun doesn’t stop here

    View Slide

  21. 1. …
    9. Set rollout rate to 30% for the initial publishing
    …and increase to 70% after 3 days,
    and increase to 100% after 6 days
    2. …
    I can repeat the process in 3 and 6 days again!

    View Slide

  22. ● Own Play Store, managed by us
    ● Another Play Store, managed by us
    ● Another Play Store, not managed by us
    ○ Providing APK in another way
    We have apps in other stores too

    View Slide

  23. Solution: Android publishing (CLI) tool

    View Slide

  24. Half time show
    ● Local build time isn’t a problem due to flavor filters
    ● Release process is better for developers due to the publishing tool

    View Slide

  25. Half time show
    ● Local build time isn’t a problem due to flavor filters
    ● Release process is better for developers due to the publishing tool
    ● but… what about our CI?
    ➡ He, we have flatrate, doesn’t matter. Right?

    View Slide

  26. Half time show
    ● Local build time isn’t a problem due to flavor filters
    ● Release process is better for developers due to the publishing tool
    ● but… what about features for single customers only?
    ➡ We don’t need it right now. But maybe sooner than we think…

    View Slide

  27. ● Reminder: app with a dependency to a library which provides flavors
    ● Problems:
    ○ Other libraries can include the “white-label” library
    ○ Single features are hardly to implement and could accidentally leak into other parts
    Start of an improved app architecture

    View Slide

  28. ● Reminder: app with a dependency to a library which provides flavors
    ● Problems:
    ○ Other libraries can include the “white-label” library
    ○ Single features are hardly to implement and could accidentally leak into other parts
    ● Solution:
    Move white-label library back to the app and make a standalone project out of it so that other
    libraries can’t access the white-label parts anymore
    Start of an improved app architecture

    View Slide

  29. Old architecture New architecture
    - app
    build.gradle
    | include("lib-wla")
    | include("lib-logger")
    | include("feature-registration")
    | include("feature-ride-creation")
    src/main/someKotlinClasses
    - lib-wla
    - lib-logger
    - feature-registration
    - feature-ride-creation
    - ioki/app
    build.gradle
    | include(":ioki-library:lib-core")
    - lib-core
    build.gradle
    | include("lib-logger")
    | include("feature-registration")
    | include("feature-ride-creation")
    src/main/someKotlinClasses
    - lib-logger
    - feature-registration
    - feature-ride-creation

    View Slide

  30. Old architecture New architecture
    - app
    build.gradle
    | include("lib-wla")
    | include("lib-logger")
    | include("feature-registration")
    | include("feature-ride-creation")
    src/main/someKotlinClasses
    - lib-wla
    - lib-logger
    - feature-registration
    - feature-ride-creation
    - ioki/app
    build.gradle
    | include(":ioki-library:lib-core")
    - lib-core
    build.gradle
    | include("lib-logger")
    | include("feature-registration")
    | include("feature-ride-creation")
    src/main/someKotlinClasses
    - lib-logger
    - feature-registration
    - feature-ride-creation

    View Slide

  31. ● Hard separation between “core” functionality and white label apps
    ○ Usage of “flavors” in “core” is technically not possible
    ○ Single features can be implemented in the “white label apps” project without touching the “core”
    ● Improved build time (also on CI)
    ○ Core has only be build once and can be reused for all apps
    ● We can set different responsibilities between our Android teams… wait, what?
    Solves quite a lot of problems

    View Slide

  32. Welcome on board,
    project implementation team (PIT)

    View Slide

  33. ● As we focused on creating WLAs, we lost the focus on features and bug fixing
    Android team can focus on…
    Android development again!

    View Slide

  34. ● As we focused on creating WLAs, we lost the focus on features and bug fixing
    ● Solution:
    A new cross-functional team was born/hired.
    Focusing on: Project implementation specifics
    Android team can focus on…
    Android development again!

    View Slide

  35. Summary
    ● Our initial release process is still used as a foundation
    ● Decreased local build times with build flavor filters
    ● Improved (manually) release process by creating a publishing tool
    ● Adapt app architecture to (not only) improve overall build time
    ● Introduced a second Android team who focus on WLAs and
    specific features only

    View Slide

  36. Outlook
    ● Publishing “core” library to internal nexus
    (and consume library in WLas)
    ○ Decrease release build time (on CI)
    ○ WLA and core library has independent release circles
    ○ No testing on linting on release day anymore (for core lib)
    ■ Happen when a core lib does a release
    ○ New WLAs and WLA hotfixes are independent from core library changes
    ○ … More?

    View Slide

  37. ● We could only scale and publish so many apps easily and healthy because we
    ○ invested in our tooling regarding release process and build times.
    ○ tackle problems when we already see potential problems in the (near) future.
    And not at the time when we already have those problems!
    ● You should care about those process as much as you care about your applications source code.
    ● Releasing is a first class citizen!
    Conclusion / final words

    View Slide

  38. Thank You,
    Any questions?

    View Slide