Mobile app release strategies

Transcript

1. App release strategies Typical / Standard / „Default” / Small project
2. Typical / Standard / „Default” / Small project Typical / Standard / „Default” / Small project
3. Typical / Standard / „Default” / Small project Made @ draw.io
4. Typical / Standard / „Default” / Small project Made @ draw.io
5. Typical / Standard / „Default” / Small project Made @ draw.io
6. Typical / Standard / „Default” / Small project Made @ draw.io
7. Typical / Standard / „Default” / Small project
8. long development phase Typical / Standard / „Default” / Small project
9. long development phase 1 dev responsible for the release Typical / Standard / „Default” / Small project
10. long development phase 1 dev responsible for the release easy to miss deadline Typical / Standard / „Default” / Small project
11. long development phase 1 dev responsible for the release easy to miss deadline lot of features released at once Typical / Standard / „Default” / Small project
12. Why stable & often releases matters - short history Why stable & often releases matters - short history
13. Big player’s process: Skyscanner Big player’s process: Skyscanner http://codevoyagers.com/2016/08/23/the-present-and-future-of-app-release-at-skyscanner/
14. Decouple features from binary Big player’s process: Skyscanner Popular case: Spotify
15. Feature flags Big player’s process: Skyscanner
16. Release train Big player’s process: Skyscanner
17. Example usage Big player’s process: Skyscanner
18. On the other hand… On the other hand…
19. On the other hand… On the other hand… ~253 MB! http://blog.timac.org/?p=1707
20. Bonus Bonus
21. Phased Releases @ App Store Phased Releases @ App Store
22. Phased Releases @ App Store Phased Releases @ App Store
23. Summary Summary • stable releases are important • decoupling features from release & • feature flags & • staged rollouts can help • New in iTunes Connect: Phased (staged) Rollouts
24. Pikor @pikorpikorpikor