Scheduled releases @ Commit Porto 2016
•
2 gostaram•799 visualizações
GetYourGuide keeps their mobile apps on a tight two-week release schedule to move faster with smaller experiments, improve quality and user satisfaction, and establish a solid continuous delivery process. Releasing frequently allows fixes to not be delayed and for unfinished features to be merged and toggled. This has led to 7 releases in the last quarter compared to 3 previously, more experiments launched, and positive app review trends despite moving quickly. Maintaining the process requires continuous work but provides ownership and a stable set of scripts.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Scheduled releases @ Commit Porto 2016
Semelhante a Scheduled releases @ Commit Porto 2016 (20)
Último
Último (20)
Scheduled releases @ Commit Porto 2016
- 1. Scheduled releases Why GetYourGuide keeps its apps on a tight release schedule
- 2. Me iOS Engineer @ GetYourGuide GmbH FEUP alumnus @banaslee
- 3. GetYourGuide
- 4. • Find a tour • Check availability • Check reviews • Book • Redeem with your phone Getting to know Porto
- 6. • > 25k activities • > 130 countries • 2.5M customers • 14 languages • Engineering offices in Berlin & Zurich • Small product team for apps
- 7. Agenda • Context • Before • Now • Results
- 8. Native apps
- 9. Fragile environment • Running in a sandbox • Constrained memory • Limited processing power • Limited connectivity • Crashes
- 10. Local storage • Offline capabilities • Often relational databases • Data migration
- 11. Provisioning • Apps running on device must be signed • Registered developers • Complicated provisioning setup
- 12. Volatile environment • New technologies every year • Users are constantly updating their devices • Not the gold rush it used to be • Keeps you on your toes
- 13. App Stores
- 14. App Stores • Main (and mostly only) distribution channel • Apple says 65% of downloads come from search • Opaque ranking system • Hard to optimise due to limited amount of data • User acquisition is hard and expensive Source: https://developer.apple.com/app-store/search-ads/
- 15. App approval times (iOS) • Most apps are now reviewed in 24 hours Source: appreviewtimes.com 0 20 40 60 80 1 2 3 4 5 6 7 8
- 16. 0 days approval time on Android
- 18. 80% users using latest version 72 hours after update on iOS / 96 hours on Android
- 19. 97% number of sessions from the 5 most recent versions
- 20. 33 versions number of different versions live during the past two weeks
- 21. Experimentation
- 22. Missions • We have engineers, PMs and designers split in mission teams • Missions around metrics • Conversion • Repeat • Acquisition • ...
- 23. Hypotheses & Experiments • Build the right product • Maximise learnings • Smaller feedback cycles • Improve customer experience
- 24. Apps haven’t yet fully embraced experimentation
- 25. Before
- 26. Feature driven • Branches to isolate unfinished features • Builds for different quality stages • Automated builds • Automated testing • Manual release
- 28. Spirits were down • Release estimates slipped • Scope creeping • Failing goals
- 29. Now
- 30. Release every two weeks • An experiment on process • Focus on focus • Keep a continuous stream of updates • Fixes are not hostage of moving release dates • Process not new but not common on small teams
- 31. Keep merging • Feature toggles • Unfinished features are merged to master
- 32. Simpler processes • Automated testing • Test builds • Localised assets
- 33. Release notes • Copy write • Translate
- 34. Continuous Delivery • Every change can be pushed to the store • Built over our CI • Test builds • UI tests • Deployment pipeline • HockeyApp • TestFlight • Release
- 35. Fastlane • Toolchain for Continuous Delivery • iOS • A bit on Android • Streamlined process • Moved separate scripts under Fastlane lanes • Adopted Match for simpler code signing
- 36. Results
- 37. Moving faster • 7 releases in Q2 vs 3 in Q1 • 5 experiments launched in Q2 vs 2 previously (Q1 & Q4’15) • Smaller yet bolder experiments • App Store features diluted some metrics
- 38. Quality & User satisfaction • “Move fast and break things” • Positive trend in reviews 0% 0% 1% 1% 2% 2% November December January February March April May June Crashes/Sessions
- 39. Quality & User satisfaction • “Move fast and break things” • Positive trend in reviews 1 stars 2 stars 3 stars 4 stars 5 stars 6 stars November December January February March April May June iOS Android
- 40. Quality & User satisfaction • Secret settings screen • Remote overrides
- 41. A solid process • A more stable set of scripts for CI • Scripts coverage extended • Pushing to store • Importing localised assets
- 42. A solid process • Requires • Continuous maintenance work • Expertise in CI and testing tools • Provides ownership of the process
- 43. Long path ahead Attribution: http://tgos.co.uk/skills/climb-every-mountain-how-to-start-scrambling
- 44. Links • https://appreviewtimes.com • https://developer.apple.com/app-store/search-ads/ • https://fastlane.tools • https://www.facebook.com/notes/facebook-engineering/timed-releases-for-mobile- apps/10151078442213920/ • https://www.youtube.com/watch?list=PLdr22uU_wISpW6XI1J0S7Lp-X8Km- HaQW&v=DWw1ankfqO0
Notas do Editor
- I’m a software engineer who has been building iOS apps since 2010. I also graduated at this school and I’m very pleased to be here today speaking to you all.
- I don’t know how many of you have heard of GetYourGuide before Commit. GetYourGuide is a marketplace for tours and activities. We sell tours but we are not a tour operator!
- Simpler is maybe to put you all in an hypothetical situation: consider you are in Porto for a conference and you have your Sunday free to get to know the city (pause). In this case you can check getyourguide.com and find the typical bus tour around the city, a wine tasting experience or a relaxing tour in Douro river from where you can enjoy the gorgeous views of both Porto and Gaia river shores. For any activity you can read user reviews and book on the go, from your phone, and pay with Paypal or credit card. Our app also helps you find your way to your booked activities and act as your ticket!
- GetYourGuide is a startup in the travel industry that has built an online marketplace for tours and activities that can be booked in advance. Largest online catalog for tours [platform to sell activities / more than 26k activities in N countries / 14 languages / user markets: Europe / UK / Australia / USA / Asia / Latin America]
- We have engineering offices in Berlin and Zurich. Our small apps team, has 4 front-end engineers, 2 per platform, and a back-end engineer, alongside a product manager and a designer.
- This talk is going to share our experience as a small team working on a tight release schedule for native apps in the travel industry. I’m not here today to show a recipe for success.
- Apps crash easier than webpages
- Not your regular front-end developer
- Last 14 days
- We at GetYourGuide aim to build our products around experiments and hypotheses.
- Hard to acquire users to get data
- Release process was overlooked because it didn’t happen so often
- Big teams like Facebook are doing this for some years now (many engineers working on the same app) If you have a big team and want to understand how this impacts you, there is a nice blog post from Facebook from 2012 and a very nice talk from a Spotify iOS Engineer from UIKonf 2015. They go into more detail on the benefits this brings on bigger teams.
- 3 months ago we decided we need to change something. As an experiment, we decided to impose a hard deadline on all of us. Every two weeks we’d be releasing an update for the app with whatever is ready to be released. <why defining a constraint on the release time?> From there it was easy to identify some things that would help us achieve that: we traded our quality checkpoints for feature toggles; some of our processes needed to happen more often, like localisation, automated testing and test builds; copywriting and translating release notes was now a bigger burden and we didn’t need it.
- 3 months ago we decided we need to change something. As an experiment, we decided to impose a hard deadline on all of us. Every two weeks we’d be releasing an update for the app with whatever is ready to be released. <why defining a constraint on the release time?> From there it was easy to identify some things that would help us achieve that: we traded our quality checkpoints for feature toggles; some of our processes needed to happen more often, like localisation, automated testing and test builds; copywriting and translating release notes was now a bigger burden and we didn’t need it.
- 3 months ago we decided we need to change something. As an experiment, we decided to impose a hard deadline on all of us. Every two weeks we’d be releasing an update for the app with whatever is ready to be released. <why defining a constraint on the release time?> From there it was easy to identify some things that would help us achieve that: we traded our quality checkpoints for feature toggles; some of our processes needed to happen more often, like localisation, automated testing and test builds; copywriting and translating release notes was now a bigger burden and we didn’t need it.
- We found we were actually moving towards a continuous delivery setup. I won’t cover much about CD as João has already covered much of the topics that provide you with the right context. I’ll just highlight what I believe is relevant for our use case. We had some CI in place with commits and pull requests to master triggering some automated builds; We had a deployment pipeline with HockeyApp and TestFlight, this one for iOS; We had user acceptance tests both automated and manual; We needed to do it faster and more reliably. We moved to Fastlane to streamline the release process. We started using Match to simplify signing.
- Started as a list of scraping tools that interacted with Apple Developer dashboard Now has a very comprehensive list of tools for shipping stuff
- Again, we are a small team. We believe the benefits would be an order of magnitude greater if we had double the size.