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

Continuous Mobile App Delivery

Continuous Mobile App Delivery

Release management is a major part of our daily work as well as regular app development. Frequent release is essential to survive in this fast-paced industry, which, however, gets harder and harder to manage as the project continues because the specification gets increasingly complicated and business will expand to different countries, which means you need to support more languages. What you need to care about is not only apps for your customers but also internal apps whose audience can be developers, product managers, community managers and QA team.

In this talk, Yusei will share how Cookpad copes with the complexity of release management by covering different topics ranging from basics like how to schedule releases properly to advanced topics like how to leverage ChatOps.

Yusei Nishiyama

February 14, 2019

More Decks by Yusei Nishiyama

Other Decks in Technology


  1. Release management is hard and keeps getting harder and harder

    As your project continues: • The team gets bigger • Build time gets longer • Your app supports more languages • You have more build configurations 2
  2. Previous talks and blog posts • Building iOS Apps at

    Scale • Continuous App Delivery 4
  3. Cookpad • 40 million monthly average users • Available in

    70 countries • Over 2 million recipes 5
  4. How we've been developing since 2014 • The number of

    iOS Engineers • 1 → 12 • Build Time • Nothing (Objective-C) → 20 mins • The number of supported languages • 1 → 17 6
  5. 7

  6. Agenda • How to schedule release • How to automate

    release (with a Slack bot) • Case Study: Cookpad 8
  7. Release Schedule • Frequent • Release changes incrementally • Consistent

    • It should be usually non-negotiable • Independent of the Product development cycle • Harness web-based feature toggles1 1 https://martinfowler.com/articles/feature-toggles.html 9
  8. App Versioning • Programmatic versioning • Auto increment • CI

    build number • Version-agnostic code base • Translations with a fallback language • Applying version info on build time 12
  9. Tips: Get App Version from Connect lane :app_version do |options|

    Spaceship::Tunes.login Spaceship::Tunes.select_team app = Spaceship::Tunes::Application.find(options[:bundle_id]) latest_version = app.edit_version || app.live_version latest_version.version end 13
  10. Agenda • How to schedule release • How to automate

    release • Case Study: Cookpad 14
  11. Remote Build Server • Make your builds independent from a

    specific machine environment • Keep the history • Use Fastlane match2 to provision servers 2 https://docs.fastlane.tools/actions/match/ 15
  12. Targets of App Release It's not only your customers •

    A developer, so that they can debug a feature on a real device • A product manager, so that they can try out a work-in- progress feature to confirm that what’s being built is actually what is wanted • QA team, so that they can test a release candidate 17
  13. 18

  14. Different Build Configurations • The bundle ID can be different

    so that internal testers can have multiple apps installed on their devices • The server environment can be different • Enabled features can be different 19
  15. ! • Who's going to trigger the build? • How

    can we decide what parameters to send? 22
  16. GitHub Webhooks + Label • Specify a PR that needs

    to be distributed with a GitHub label • If CI (Fastlane) founds a specific label it distributes the app to internal members with an Enterprise codesign 23
  17. GitHub Webhooks + Label • Specify a PR that needs

    to be distributed with a GitHub label • If CI (Fastlane) founds a specific label it distributes the app to internal members with an Enterprise codesign • master and branches with an RC prefix are distributed automatically 24
  18. GitHub Webhooks + Label (Failed) • CI tends to be

    busy • Too many internal releases • People started ignoring them 25
  19. What's ChatOps? ChatOps is the use of chat clients to

    facilitate software development and operational tasks — Yusei Nishiyama 27
  20. Bot Version 1 • Pattern match with regex • deploy

    {branch_name} to {destination} • Commands are hard to remember • Operational mistakes • Hard to know available options 29
  21. How to Design Your Bot Read Message Guidelines4 • Replace

    the original message instead of making a new one • Cleaning up the entire interaction at the end to summarize what has happened • If it consists of multiple steps, those steps should be visible only to the user until the entire action is completed 4 For more information check https://api.slack.com/docs/message-guidelines and https://github.com/slackapi/sample-message-menus-node 32
  22. Choose Right Technology • Incoming Webhooks • Slash Commands •

    Events API • RTM (Real-time messaging) API • Web API 33
  23. RTM API vs Events API5 • RTM API • WebSocket-based

    • More responsive ("__ is typing...", online status) • Events API • HTTP-based • Scalable 5 For more details check out https://api.slack.com/faq#events_api and https://api.slack.com/events 36
  24. Questions You Should Ask Yourself • Post, receive, or both

    • Only messages or including other events • A need of your web server 37
  25. "Which API is right for your Slack app?" 6 6

    https://medium.com/slack-developer-blog/getting-started-with-slacks-apis-f930c73fc889 38
  26. Preparing Endpoints • Handle mentions • Handel interactions (e.g. a

    button is pressed) • Return dynamic options 39
  27. Tips: Handle Timeout You must respond within 3 seconds. If

    it takes your application longer to process the request, we recommend responding with an HTTP 200 OK immediately, then use the response_url7 { "type": "interactive_message", "actions": […], "callback_id": "select_simple_1234", … "original_message": {…}, "response_url": "https://hooks.slack.com/actions/T012AB0A1/123456789/JpmK0yzoZDeRiqfeduTBYXWQ" } 7 https://api.slack.com/interactive-messages 44
  28. Tips: Debugging with ngrok • ngrok exposes local servers to

    the public internet over secure tunnels • A free plan is available8 8 https://ngrok.com/pricing 45
  29. Agenda • How to schedule release • How to automate

    release • Case Study: Cookpad 46
  30. Developing New Features • Run deploy chatbot command to distribute

    a working-in-progress feature to internal members: • To test it on different devices • To check it with PM • To ask QA to test it 48
  31. Wednesday: Code Freeze • Run code_freeze chatbot command to: •

    Create a release candidate branch off from master • Ask translators to translate new phrases • Post a list of changes to Slack • Run deploy command to make an RC build for QA team 49
  32. Friday: Submit • Run deploy chatbot command to: • Archive

    the RC and upload it to App Store Connect • Run submit chatbot command to: • Submit a new version with a specified build • Post a message to Slack 50
  33. Monday: Release • Run release chatbot command to: • Release

    "Pending Developer Release" version • Download dSYMs and upload them to a crash reporting service • Create the next version in App Store Connect • Post a message to Slack 51
  34. Wrap-up • Release frequently • Stick to a constant schedule

    • Set up remote build servers • Leverage chat application to do operational works 55