Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

QA Process



Release Process

Mobile Release Process v1.2
Last edited: 2/12/2019

In an effort to standardized the mobile release process, follow the steps below for a predictable rollout out new versions of SimplyE mobile applications.

Android

The release process today can be a bit confusing; challenges come up because we have two different platforms that are not always in sync (iOS/Android), and both of those require approvals from the Apple App Store and the Google Play Store, respectively. The Release processes, along with some other technical documentation, can be found by the Mobile team here.

...

  1. Pre-Release Steps

    1. Three to five working days before the targeted release date, depending on the size of the release (bug fix or feature), a code freeze goes into effect where no new additions are added to the codebase.

    2. After all tickets for the release have been merged into develop, create a new release branch, e.g. git checkout -b release/3.6.0 and push it upstream.

    3. Verify all unit tests are passing

    4. Verify all tickets have been moved into the Ready for QA state in Jira. The completed tickets serve as the basis for QA release notes notifying QA of what tickets should be tested.

    5. Create pull request against master from the release branch.

    6. Create QA build/release candidate and upload to Firebase, Google notifies testers that the build is available

    7. (iOS Only) Stage release candidate in App Store Connect and set to manual release

  2. Current State Release Steps 

    1. iOS

      1. Get the sign off from QA for the build from

...

      1. Joseph Dalton

...

      1. Based on commit history and completed Jira tickets, construct text to be shown in the

...

      1. What’s new field

...

      1. in the App Store. This text should be approved by Risa Wolf in Jira ticket or official email for visibility.

...

      1. Check with Risa Wolf to see if there are any new screenshots that should be added to the

...

      1. App Store listing.

4. Increment version name and number, tag release branch in Github.

5. Run Fastlane commands to upload build to Goolge Play Beta , enter approved "Whats new" text and new approved screenshots. Use the the release version as the internal release name.

6. Resolve any new Google Play Console errors or warnings.

7. Run beta for 3 days, if there are issues, fix the issues and start again from Step 1 otherwise if there are no issues promote beta to production with Risa Wolf signing off.

8. Respond to any negative Google Play Store reviews where their specific issues have been addressed in the latest release.

iOS

      1. Add the approved Whats new text to the App Store listing.

      2. With product team approval, manually release previously approved production build in the App Store.

      3. Notify #Simplified channel in the NYPL Digital Slack workspace that the release has gone out.

    1. Android

      1. Get the sign off from QA for the build from

...

      1. Joseph Dalton

...

      1. Based on commit history and completed Jira tickets, construct text to be shown in the

...

      1. What’s new field on

...

      1. Google Play. This text should be approved by Risa Wolf in

...

      1. Jira ticket or official email for visibility.

...

      1. Check with Risa Wolf to see if there are any new screenshots that should be added to the

...

      1. Google Play listing.

4. Increment the build number in Xcode and archive the project

5. Upload the app to the app store

6. Once the new build has completed processing, add the appropriate test group to the build, add the approved Whats new text as the test information, and Submit the app for review to notify the testers.

7. Expire any the previous TestFlight builds

8. Run beta for 3 days, if there are issues, fix the issues and start again from Step 1.

9. Run beta for 3 days, if there are no issues copy the approved "Whats new" text as the description, and check with Risa Wolf for any new screenshots that should be add to the App Store listing.

10. With Risa Wolf sign off, submit the tested build for review.

      1. Increment version name and number, tag release branch in Github.

      2. With product team approval, run Fastlane commands to upload the build to Google Play, enter approved Whats new text and any new approved screenshots. Use the release version as the internal release name.

      3. Resolve any new Google Play Console errors or warnings.

      4. Notify #Simplified channel in the NYPL Digital Slack workspace that the release has gone out.

    1. Post Release

      1. Merge release branch into master

      2. Monitor Crashlytics 

      3. Monitor email error reports

      4. Respond to any negative Google Play Store / Apple

...

      1. App Store reviews where their specific issues have been addressed in the latest release.