Releases (internal)

From Status Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search


As part of this we want to document how we do releases and spread knowledge for this.

Release cutting/mangement process

  • Branch of develop 1-2w before release
  • Create PR something like: this
  • (Continuous) Cherry pick bug fixes and only critical bug fixes _from_ develop to release branch
  • Use script/ 0.9.14 script to tag each cherry-pick for accurate build info, make sure .env and have exactly the same content,
    cp .env
  • Communicate with QA and devs to ensure all critical bugs are caught and fixed
  • Make sure TF is off in release build for final RC
  • Upload binaries for both Android/iOS
  • Fill out release notes from comms team (short version) in description

Testing process

Keep in mind that Apple needs to verify TestFlight builds for ~ 2 days so release candidate should be ready 2 days prior the release date - identify the features / bugfixes to be included in release. This should be done by evaluating current develop state which basically will be a release branch cut on particular day. Make sure all criticals and majors are planned to be fixed so we are not delivering crashes. Add release label for easy understanding

  • once the scope is defined - create a new tab here and list the scope here. Do not forget to keep this up to date
  • make sure all bugs are assigned to a developer at the very beginning so nothing is left uncovered for weeks.
  • test PRs containing bug fixes important for release. Once tested and merged to develop - move the PR to Cherry-pick for release column so release owner is aware that this PR should be merged into release branch
  • run regression when all the bugfixes are merged into branch
  • run upgrade testing carefully

IMPORTANT: update team daily on testing state for release: what’s left, what areas are blocked for testing, what new issues found. Remind to check release progress google sheet + specify explicitly (even if obvious) what can’t be tested now and why

  • On release branch: check testfairy is OFF, Mainnet is not shown, versions are up to date (0.9.14 for example). That may be done when is the very latest build is approved for release and testing is done. For all other release branches you may leave TF = ON for testing and logs.
  • create test flight build. Check simple sanity that build is alive. Release.

Release checklist

Please find the checklist here

There is a sample of tasks list below to be done for each release

  • apk submitted to Playstore (but not approved yet)
  • ipa submitted to iTunes Connect (but not to external testers)
  • Blog Post
  • Social Copy @jonny.z
  • UI Assets for blog post @denis-sharypin
  • Email Prep @jonny.z
  • Prepare responses to FAQs @cryptowanderer
  • Seed release notes and FAQs to key community members @cryptowanderer


  • Approve playstore release
  • Submit TestFlight build to external testers (check "automatically notify testers")
  • Publish blog post
  • Send announcement mail

Release note / comms process

TBD. Chris?

Release for Android

Use the apk created by the jenkins build.

Go to > Release Management > Release dashboard > Manage Alpha > Create Release (using your account, request access to Jarrad) Complete the form and save, wait for iOS build before coming back to it to actually release

Release for iOS

Build the .ipa locally using generic iOS device setting

In product menu chose archive

Upload the build in xcode menu > dev tools > application loader

On iTunes connect go to TestFlight tab

You should see your build 'ready for review' in the builds/iOS menu, it should be `ready for review` which means you can submit it to external testers once QA accepted it. It does not mean you can release right away because once you submit it to external testers the app may or may not go in review process which can take days.

To submit for review go to External Testers > build tabs > click on the plus sign > select the build

Once it is accepted the build will be live for external testers and you can add the build to the other TestFlights groups and release on PlayStore


As a release cutter, make sure you have access to:

  • iTunesConnect (need access to [email protected] account, ask Roman)
  • Google Play Store (need access to console, ask Jarrad)
  • Build system with proper certificates for both platforms (Jenkins, local, Fastlane, ~TBD) (need private key to sign the iOS build, ask Oskar)


  • How to answer iTunesConnect questions and submit build. TODO: Document here (yes to encryption and exemption, IIRC - easiest option that is true).
  • How to submit build to Play Store
  • How to approve Status for App Store release