Storia.me App Rollout: Better Feedback Loop, Faster Iterations

When developing Storia.me iPhone app, we had the following cirqles to deliver to:

  • Developers
  • QA
  • Early adopters
  • General Audience (AppStore)

And the following problems to solve:

  • Provide Beta access with faster update pace and immediate critical bug fixing for early adopters (as in microsoft’s inner circle);
  • Make AppStore version as stable as possible;
  • Receive feedback on earlier stages, experiment with a limited set of users and influencers.

A scheme we came up with eventually, has three (four in special cases) versions before the final AppStore release. Each version is rolled out out for certain circle, with different readiness level.
scheme

Storia Alpha

Internal build for developers. After code is frozen, feature-complete version is sent to Preprod.  Alpha version may be used as a proof-of-concept prototype, since it usually doesn’t require QA stage. Distributed via hockeyapp. Connected to dev server.

Storia Preprod

Internal build for QA team, before we release stable version. After critical and major bugs fixed, Preprod becomes a Beta. Distributed via hockeyapp. Connected to preproduction server.

Quite often preprod version is tested together with design team, in order to see how well the mockup works in extreme cases.

Storia Beta

Stable version for early adopters. Helps in revealing bugs, inconsistencies and everything else that fell out of scope during previous stages, shows overall initial reception. Has a 1-week period for testing, before AppStore submission.

Version that is used by stakeholders, everyone in the company and users from countries, where Storia is not released yet. Distributed via hockeyapp. Connected to production server.

Why hockeyapp?

  • It is cross-platform, meaning that we can extrapolate iOS scheme to Android.
  • It shows new updates instantly, meaning we can be sure that most Beta users are using the latest version.

Bug fixing and merging

Fixes are merged into current version branch. If QA team finds a bug in Beta version – fixed are merged in Beta.

It is obvious, that we cannot hotfix an AppStore version =) Critical fixes are tested in Beta and issued as an AppStore update (depending on severity). Minor fixes are added to the next planned version.

Special cases, Storia Testflight

testflight_case

Testflight version is identical to Beta and the one submitted to AppStore. Connected to production server. We use it when we need to test a certain feature on production server privately. We needed to test video recording & processing on backend, but couldn’t rollout this features to Beta access (they could have produced a lot of broken content). Testflight Version was internally tested on production server by dev and QA teams, and proceeded to App Store once all obstacles were moved out of the way.

  • Q: Why to AppStore, and not to beta?
  • A: We rolled out video recording and playback features simultaneously for general public and Beta access).

Bug fixing for Testflight version sometimes involved rolling out the fix in Beta, since hockeyapp update takes a bit less time to process.

For the past 9 months, come hell or high water, this flow proved itself to be efficient and transparent. It took two sprints initially to get used to the scheme and tune it a bit. Release cycle is stable, updates work well, adopters get new features faster, team receives feedback earlier.

I would love to hear criticism, or get a fresh look at similar distribution process in your teams =)

Many thanks to Rishat, Ksenia for edits.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s