7Mind Brain

mobile-release

3 min read

Summary: How the 7Mind mobile apps (Flutter monorepo) ship to TestFlight and Play Store on a weekly cadence. Sources: Notion extraction 2026-05-15 (New 7Mind Release Process, New Release Process, Releasing 7 Mind 3.0.x) Last updated: 2026-05-15

Cadence

A release runs every Thursday. The role rotates and is called the “Release Guru” (rotation maintained in Notion). The default is one release per two weeks, with exceptions for urgent bug fixes that ship out of cycle.

Pipeline Overview

The mobile apps live in the 7mind-mobile-apps-monorepo repo. Releases are driven by changelog automation plus a manual trigger in Codemagic.

  1. Every Thursday at 10:00 a PR named chore(release): Publish packages is auto-created. It collects all changes merged to main before 10:00.
  2. If extra changes land after 10:00 and should ship in the same release, the Release Guru re-runs the Prepare Changelogs GitHub Actions workflow on main, which regenerates the PR.
  3. After PR checks pass, the Release Guru merges the changelog PR into main.
  4. Once all post-merge GitHub Actions workflows complete (build artifacts), the Release Guru opens Codemagic and starts a new build for the monorepo against the new git tag (for example seven_mind-v0.0.32).
  5. Codemagic runs two workflows: iOS and Android. Both use the same git tag. Important: iOS does not accept +N tag suffixes, so tags must follow the form seven_mind-vX.Y.Z (no build-number suffix).
  6. Build progress is observed in the Slack channel #internal-releases-mobile-apps.
  7. When iOS and Android builds finish, the iOS build lands on TestFlight and the Android build lands on Play Store internal track.
  8. The Release Guru posts a release message in #releases-7mind-flutter using the changelog.md from the merge commit, and writes the human-facing release notes from it.

Phased Rollout

Releases go out in phases:

  • iOS: phased release through App Store Connect.
  • Android: phased rollout, brought to 100% over roughly a week.

DACH staging release lands Friday, production release Monday (older “DACH Technical Release plan” doc).

Code Freeze and Branching

Code freeze and git release strategy were items still being formalized in 2025 (pending in the DACH launch plan checklist). TBD — confirm the current rule (whether release branches are still cut, or whether main-line releases are the standing convention) and link to the active Notion process page.

Testing Strategy

The release plan calls for:

  • Unit tests on bloc, repos, services, managers, extensions, models. Codecov is configured.
  • Patrol integration tests for new features. Run before tagging.
  • Subscription flow smoke tests (purchase, restore, dunning) before promoting a build.

Patrol tests live in the monorepo. TBD — confirm the canonical test command and CI job name, and surface it in flutter-app.

Communication Channels

  • #internal-releases-mobile-apps — build status and failures
  • #releases-7mind-flutter — human-readable release messages
  • #activation-team-public — questions about SKUs and pricing surfaces

Manual Steps That Still Hurt

The process is largely automated but several steps remain manual: triggering Codemagic, ensuring what's new translations are ready, submitting for review, walking the Android rollout up. These are flagged in the Notion source pages as candidates for further automation.

Graph View

Backlinks