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

Exploring Mobile Release Management: Strategies and Best Practices

Exploring Mobile Release Management: Strategies and Best Practices

In this talk, we will explore effective strategies for mobile release management, drawing insights from various industry leaders (Uber, Soundcloud, Skyscanner, etc). We'll delve into the use of release trains for efficiency, assigning roles for streamlined releases, and employing Mobile DevOps for agile cycles. We will compare feature-based releases and release train models, discussing their pros and cons. We'll also cover automated testing, CI/CD processes, and the importance of monitoring and feedback in post-release stages. The goal is to gain a comprehensive understanding of mobile release management, tailored to suit different team dynamics and project scopes.

Rygel Louv

April 20, 2024
Tweet

More Decks by Rygel Louv

Other Decks in Programming

Transcript

  1. WHAT IS RELEASE MANAGEMENT? - Release management is a discipline

    within software engineering that focuses on the process of planning, scheduling, and controlling the movement of software releases from development and testing environments into production. - This ensures that the software can be reliably released to users in a scheduled, consistent, and repeatable manner.
  2. WHAT IS RELEASE MANAGEMENT? Key components of release management include

    • Planning • Scheduling • Coordinating • Testing and Quality Assurance • Deployment • Monitoring, support and maintenance
  3. CHALLENGE OF MOBILE RELEASE MANAGEMENT? Mobile faces several unique challenges

    that can complicate the process of developing, testing, and deploying mobile applications. Some of these challenges include • Standalone applications • OS fragmentation • User adoption • App Store review and approval • And more…
  4. RELEASE PLANS Create a checklist from your release plan, outlining

    all tasks and timelines for an overview of the project. • The features and functionalities shipping with the release • The teams that will work on the deliverables • A timeline for the overall release • Different stages of the release process • Stakeholders sign off
  5. THE RELEASE MANAGER • Responsible for executing all the steps

    of the release process • This is the driver of the train • 1 Release Manager per platform • This is usually a rotation role within the mobile team
  6. CHALLENGE: RELEASING A NEW BINARY FREQUENTLY Increasing the frequency of

    releases is a key part of keeping the pace in delivery. Frequent releases help us to experiment and iterate on our features faster. We can get valuable data about user behaviour faster so we can react on them faster.
  7. CHALLENGE: RELEASING A NEW BINARY FREQUENTLY We ship a new

    app version every week, which means we have a release cut weekly.
  8. RELEASE BRANCHING: DECOUPLING RELEASING FEATURES FROM RELEASING THE BINARY When

    starting a release, teams should be isolating production- ready code from any code still under development. Create a Release branch
  9. FEATURE BASED If the features take one week to be

    built and veri f ied, you’ll roll out the release in a week. If it takes three weeks, your release will ship in three weeks. This approach is usually taken by agencies and smaller orgs. • For smaller teams
  10. RELEASE TRAINS App releases happen on a f ixed schedule

    and aren’t held up for any feature work; whatever code happens to be ready and merged by the time the release is cut will go out and any pending work will need to wait for a subsequent release
  11. FEATURE FLAGS • Release trains are only possible thanks to

    Feature Flags • Developers can safely have un f inished features in the release branch
  12. CONTINUOUS INTEGRATION & CONTINUOUS DELIVERY (CI/CD): BUILD, TEST & DISTRIBUTE

    • Continuous Integration: Build and Test • Continuous Delivery: Distribute your Release candidate
  13. RELEASE CANDITATE • The artifact produced by your release branch

    • The binary that will be tested and eventually deployed in production Release Candidate Release Deployment RC 2.5 v2.5
  14. TESTING THE RC: REGRESSION TESTING • QA engineers will test

    the RC artifact for regression • Make sure pre-existing feature still work as expected • Determine if release candidate is good to go • Any issue found should be f ixed in dev and cherry-picked in the release branch
  15. SUBMITTING TO PLAYSTORE • Submit to Playstore • Google/Apple review

    and approval • Phased rollout • Add release notes (usally by Growth/Marketing/Product)
  16. MONITORING ROLLOUTS POST-RELEASE • Monitor Crashlytics for bugs and crashes

    • Play/App Store reviews • Key success metrics (performances, support tickets etc..) • Increase rollout percentage if nothing major is identi f ied • For emergency issues, make a hot f ix and restart a part of the release train
  17. CONCLUSION • Plan your release • Designate a Release Manager

    • De f ine your release cadence • Adopt release trains for medium and big teams • Use feature f lags • Use a CI/CD pipeline • Test your RC for regression before each store submission • Adopt phased rollout • Monitor your release • Fix on dev and cherry-pick to release branch • Release hot f ix by restarting the build train
  18. RESOURCES • https://www.instabug.com/blog/mobile-release-best-practices • https://www.runway.team/blog/how-to-release-a-mobile-app • https://doordash.engineering/2023/11/28/how-doordash-manages-mobile-releases/ • https://bitrise.io/blog/post/mastering-the-art-of-mobile-app-releases •

    https://www.mobileatscale.com/links.html#9 • https://medium.com/@SkyscannerEng/the-present-and-future-of-app-release-at-skyscanner- b393c88972a8 • https://developers.soundcloud.com/blog/quality-mobile-trains