Wikimedia Apps/Team/Android/Release process

From MediaWiki.org
Jump to navigation Jump to search

This page documents the release process for the Android team.

Alpha releases[edit]

Alpha APKs are built automatically after patches get merged to master every 15 minutes and are available at android-builds.wmflabs.org.

Technical information[edit]

  • Web server backend login: android-builder.mobile.eqiad.wmflabs
    • Gerrit repository that contains the web page that serves the Alpha download link, and the shell script that copies the latest Alpha from the CI server to the web server. After committing a change to this repo, log on to the android-builder server, and do a git pull on /srv/builds.
$ ssh android-builder.mobile.eqiad.wmflabs
$ sudo -s
$ sudo -u android-build /bin/bash
$ cd /srv/builds

Beta releases[edit]

  1. Announce on #wikimedia-mobile connect that a new beta build is in progress and that any merging should be paused until it's done.
  2. Prepare your workspace. Ideally you should checkout a fresh copy of the repo into an empty directory, to avoid any unintended artifacts from Android Studio, gradle, etc.
    git clone git@github.com:wikimedia/apps-android-wikipedia.git
    cd apps-android-wikipedia
    
  3. Increment the patch version code. Consider updating the minor number. Please notice that you may need to create the bumpVersionCode branch before running the script.
    scripts/bump-version-code.py
    
  4. Push the version increment patch.
    git push bumpVersionCode
    

  5. Create a Pull Request for it, and merge it.
  6. For cherry-pickin' hotfix releases:
    git checkout [tag of previous production release]
    git cherry-pick ...
    git cherry-pick ...
    git cherry-pick ...
    git cherry-pick [version-bump patch]
    
  7. Start the release notes Etherpad cooking. Here are some helpful commands to look through the commit history, while filtering out uninteresting commits:
    git log --pretty=format:"%h | %cr | %s" --abbrev-commit --no-merges `git tag --list beta/* | tail -1`.. | grep -Ev 'Hygiene:|Localisation updates from https://translatewiki.net.'
    
    echo 'Volunteer contributor patches:'
    git log --pretty=format:"%h | %an | %cr | %s" --abbrev-commit --no-merges `git tag --list beta/* | tail -1`..|grep -Evi 'Dmitry Brant|Sharvani Haran|Cooltey Feng|Translation updater bot'
    
  8. Confirm the version-bump patch has merged, and update your local repo with it.
  9. Perform the actual build of the beta, production, and partner flavors.
    ~/Downloads/all-apks.sh
    

    (Or wherever you keep the all-apks.sh file.)

    This script is confidential because some partners wish to maintain anonymity. However, it looks something like this:
    #!/usr/bin/env bash
    set -euo pipefail
    make-release() { scripts/make-release.py "$@"; }
    make-release --beta
    make-release --prod
    make-release --amazon
    # TODO: version script and pass the partners as a string.
    for channel in foo bar baz boo bug oog; do
      make-release --channel "$channel"
    done
    

    When the script finishes, all of the built APKs will be placed in the /releases directory. You'll notice that each flavor of the build has five APKs associated with it, one for each platform that we support:

    • arm64-v8a - used in most modern higher-end devices.
    • armeabi-v7a - used in older and lower-end devices.
    • x86 - used in some older and lower-end tablets.
    • x86_64 - used in some newer and higher-end tablets.
    • universal - combination of all above platforms, but much larger APK size.

    When distributing the APK manually (whether for a partner, user testing, etc.) always use the universal build. The non-universal builds are intended only for uploading to the Google Play Store.

  10. Load the built APK onto the device and install/run it and see if everything functions as expected, as a sanity check. For bonus points, try it on an API 19 device. For extra bonus points, try it with a Kindle Fire device. For super bonus points, on one of the devices enable the "Don't keep activities" developer option, and make sure nothing breaks.
  11. To install the APK programmatically onto multiple connected devices:
    declare devices=( $(adb devices|sed -nr '2,$ s_([^\t ]+).*_\1_p') )
    echo "${#devices[@]} ADB devices detected."
    
    # $1 apk
    apk_to_pkg() {
      declare apk="$1"
      aapt d badging "$apk"|
      sed -rn "0,/package: name='([^']+)'.*/ { s%%\1%p; q }"
    }
    
    # $1 apk
    apk_to_activity() {
      declare apk="$1"
      aapt d badging "$apk"|
      # TODO: only need first match.
      sed -rn "s%launchable-activity: name='([^']+)'.*%\1%p"
    }
    
    cd releases
    
    # TODO: add adb-setup to test like CI.
    # TODO: error on failure instead of manually checking results.
    for i in wikipedia-*-r-*universal.apk wikipedia-*-beta-*universal.apk; do
      for serialno in "${devices[@]}"; do
        echo "Installing $i on $serialno..."
        adb -s "$serialno" install -r "$i"
        declare pkg="$(apk_to_pkg "$i")"
        adb -s "$serialno" shell "am start -R5 -W -a android.intent.action.MAIN -c android.intent.category.LAUNCHER $pkg/$(apk_to_activity "$i")"
      done
    done
    
    cd ..
    
  12. Do some light manual testing, including search, saved pages, reading lists, history, nearby, beta-only and prod-only features, light/dark/black themes, upgrade from a previous version, and new features and churn areas identified when generating release notes.
  13. Go to the Google Play Store console, and create a new Alpha release for the Wikipedia app with 100% rollout. Upload the four platform-specific (non-universal) -r- APKs to it, and use the release notes from the Etherpad.
  14. Also in the Play Store console, create a new Production release for the Wikipedia Beta app with 100% rollout. Upload the four platform-specific (non-universal) -beta- APKs to it, and use the release notes from the Etherpad.
  15. Push the tags.
    scripts/make-release.py --beta --push
    scripts/make-release.py --prod --push
    
  16. Upload the built APKs to releases.wikimedia.org.
    # TODO: use rsync.
    scp releases/wikipedia-*-beta-*universal.apk releases1001.eqiad.wmnet:/srv/org/wikimedia/releases/mobile/android/wikipedia/betas/
    scp releases/wikipedia-*-r-*universal.apk releases1001.eqiad.wmnet:/srv/org/wikimedia/releases/mobile/android/wikipedia/stable/
    
  17. Upload the APKs to Google Drive (i.e. into a new folder accessible by QA and TSG). Sending apk URLs to QA and TSG
    Stable:
    https://releases.wikimedia.org/mobile/android/wikipedia/stable/
    
    Beta:
    https://releases.wikimedia.org/mobile/android/wikipedia/betas/
    
  18. Review the Alpha pre-launch test results in the Play Store console.
  19. Create a new "Upcoming" version of the app in the Amazon Appstore and upload the -amazon- universal APK to it.
  20. Add the release to Mobile/Release_history under the Android section's "Release notes".
  21. Optionally end email to mobile-l@, cc android@, and bcc volunteer contributors. Don't forget to call out volunteers!
  22. Send email to QA and/or TSG to start regression testing.

Production releases[edit]

Production releases are simply promotions from Beta by the product owner.

  1. Go to the Google Play Store console and promote the current Alpha release to Production. (Optionally perform a staged rollout, i.e. less than 100% to begin, then ratchet up to 100% when completely ready.)
  2. Go to the Amazon Appstore and hit the Submit button to submit the current "upcoming" version of the app for review and deployment.
  3. Send email to mobile-l@, cc android@, and bcc volunteer contributors. Don't forget to call out volunteers!

Post-release[edit]

  1. Rejoice
  2. Monitor for any new crashes in HockeyApp. Remember: since we have APKs for four different platforms, there are four different version codes organized by 10xxx, 20xxx, 30xxx, and 40xxx, with "xxx" being the actual versionCode of the APK. You should check all four of these in HockeyApp, although 10xxx and 20xxx should be the most important since these are the most widely used (armv7a and armv8a).
  3. Monitor for any new crashes in the Play Store console. These are much less likely than crashes in HockeyApp, since these crashes would imply a system-level crash before the app even loads. Nevertheless, they are possible and should be checked.
  4. Monitor the ANR rate in the Play Store, as well as the other performance metrics that the console provides. This can expose performance bottlenecks or UI slowdowns which should be investigated.