Proposed App upgrades for QA and maintenance improvements

Mobile Toolbox has ONE cross-platform production app that is intended for partner developers to add a variety of assessment types. As the primary unified development team of Northwestern and Sage, we must commit that all releases depend on all participant facing app components functioning within the production app. A local or other environment may be a good pre-indicator of functionality or used as an interim step. However, it is ultimately irrelevant if components can function outside of the app (i.e. in a local dev or test environment or in a different version of the app), since fundamentally components must work within the production app to deliver the value of the platform to our users. Efficiencies can be gained by performing QA on new builds directly using the production app. Other reliability and efficiencies are gained by unifying maintenance and upgrade support in a single location. Aside from greatly needed resource optimization and efficiency, the two specific scenarios are addressed.

Scenarios that are addressed:

1. Reduce build dependency across teams: NU can generate as many builds as they want at whatever speed they want and quickly QA before sending to Sage for an integrated build.

2. Enables E2E test/staging environment: this environment can be setup with an E2E pipeline and scoring environment for comprehensive QA before committing a build to the release.

3. Capture production fails early in the process: Functions that appear to work in local environments are caught very early on in the QA process. Examples of these functions include orientation/rotation lock, swipe gestures, and archive/upload of data. All three of these functions have historically caused significant user experience issues.

The goal of this proposal to align the primary development teams and prioritize infrastructural work so that we can get to a reliable, automated process for publishing measure libraries and streamlining QA. We are seeking feedback on the feasibility of and timeline for this work. If there are resource or technical constraints we are unaware of, this proposal can be updated to reflect changes. This work has previously been agreed upon (still some details to work through), but was de-prioritized due the urgency of supporting new studies (ICAR/schema refresh and MyCogMobile).

There are legacy reasons (ex. support for the initial validation app from June 2020) for having multiple environments and test apps, but scalability, reliability, and test automation going forward requires infrastructural upgrades. To come up to current standards in June 2023 and move forward into our renewal period we have the following recommendations for primary and partner development teams:

Recommendations

These recommendations are initially described for Northwestern (NU) but can and will be expanded for other development partners.

Android

1. Create a branch of MobileToolbox-Android from develop. This can be done once per release cycle.

2. Publish a new version of the NU measure libraries

   1. This should be automated, ideally using a github action

3. Update to new version of measure library dependency which is a one line change in Dependencies.kt

4. Increment versionCode for NU build variant which is a one line change in app build.gradle.kts

5. Commit changes and tag with format northwestern*

6. Pushing tag will trigger a github action that will build and upload release to Internal Test Track of NU's Google Play Account

   1. Sage will need a service account json file for the NU Google Play account to set this up

7. Sign-in to Google Play to edit what's new and publish test build

8. Repeat steps 2-7 until NU QA is complete

9. When NU is ready for updated measures to be included in the production release, open a PR against develop branch

Sage changes are included in this PR. The final step is for Sage to update the Github Action workflow to publish to Google Play.

iOS

1. Accept PR https://github.com/MobileToolbox/MobileToolbox/pull/1116 and start using that app to build and rebuild until NU QA is complete.

2. Alternatively, identify a different strategy that uses either that app project or MobileToolboxApp as a template.

3. QA builds can be kicked off manually, or can be set up as automated builds. *Automation of build and test is only possible if Sage has permissions to all repos needed to set up Xcode Cloud for use in building and deploying to the app store. Github actions and Xcode Cloud are brittle. Xcode Cloud is a possible solution but it is untested until permissions are granted. Any solution will need to be tested and will require effort to make sure we have redundancy and can reliably build.