kopia lustrzana https://github.com/meshtastic/Meshtastic-Android
130 wiersze
7.1 KiB
Markdown
130 wiersze
7.1 KiB
Markdown
# Meshtastic-Android Release Process
|
|
|
|
This document outlines the steps for releasing a new version of the Meshtastic-Android application. The process is heavily automated using GitHub Actions and Fastlane, triggered by pushing a Git tag from a `release/*` branch.
|
|
|
|
## High-Level Overview
|
|
|
|
The automation is designed to be safe, repeatable, and efficient. When a new tag matching the `v*` pattern is pushed from a release branch, the `release.yml` GitHub Action workflow will:
|
|
|
|
1. **Determine Versioning:** A `versionName` is derived from the Git tag, and a unique, always-increasing `versionCode` is generated from the current timestamp.
|
|
2. **Build in Parallel:** Two jobs run simultaneously to build the `google` and `fdroid` flavors of the app.
|
|
3. **Deploy to Google Play:** The `google` build job uses Fastlane to automatically upload the Android App Bundle (AAB) to the correct track on the Google Play Console, based on the tag name.
|
|
4. **Create a Draft GitHub Release:** After both builds are complete, a final job gathers the artifacts (AAB, Google APK, and F-Droid APK) and creates a single, consolidated **draft** release on GitHub.
|
|
|
|
Finalizing and publishing the release on both GitHub and the Google Play Console are the only **manual steps**.
|
|
|
|
## Versioning and Tagging Strategy
|
|
|
|
The entire process is driven by your Git tagging strategy. Tags **must** start with `v` and should follow Semantic Versioning. Use the correct suffix for the desired release track:
|
|
|
|
* **Internal Track:** `vX.X.X-internal.Y` (e.g., `v2.3.5-internal.1`)
|
|
* **Closed Track:** `vX.X.X-closed.Y` (e.g., `v2.3.5-closed.1`)
|
|
* **Open Track:** `vX.X.X-open.Y` (e.g., `v2.3.5-open.1`)
|
|
* **Production Track:** `vX.X.X` (e.g., `v2.3.5`)
|
|
|
|
The `.Y` suffix is for iterations. If you find a bug in `v2.3.5-closed.1`, you would fix it on the release branch and tag the new commit as `v2.3.5-closed.2`.
|
|
|
|
## Core Release Workflow
|
|
|
|
The entire release process happens on a dedicated release branch, allowing `main` to remain open for new feature development.
|
|
|
|
### 1. Creating the Release Branch
|
|
First, create a `release/X.X.X` branch from a stable `main`. This branch is now "feature frozen." Only critical bug fixes should be added.
|
|
|
|
As a housekeeping step, it's recommended to update the `VERSION_NAME_BASE` in `build-logic/convention/src/main/kotlin/com/geeksville/mesh/buildlogic/Configs.kt` on this new branch. While the final release version is set by the Git tag in CI, this ensures local development builds have a sensible version name.
|
|
|
|
```bash
|
|
git checkout main
|
|
git pull origin main
|
|
git checkout -b release/2.3.5
|
|
# (Now, update the version in buildSrc, commit the change, and then push)
|
|
git push origin release/2.3.5
|
|
```
|
|
|
|
### 2. Testing and Iterating on a Track
|
|
Start by deploying to the `internal` track to begin testing.
|
|
|
|
**A. Create and Push a Tag:**
|
|
Tag a commit on the release branch to trigger the automation.
|
|
```bash
|
|
# Ensure you are on the release branch
|
|
git checkout release/2.3.5
|
|
|
|
# Tag for the "Internal" track
|
|
git tag v2.3.5-internal.1
|
|
git push origin v2.3.5-internal.1
|
|
```
|
|
|
|
**B. Monitor and Verify:**
|
|
Monitor the workflow in GitHub Actions. Once complete, verify the build in the Google Play Console and with your internal testers.
|
|
|
|
**C. Apply Fixes (If Necessary):**
|
|
If a bug is found, commit the fix to the release branch. Remember to also cherry-pick or merge this fix back to `main`. Then, create an iterated tag.
|
|
```bash
|
|
# Assuming you've committed a fix
|
|
git tag v2.3.5-internal.2
|
|
git push origin v2.3.5-internal.2
|
|
```
|
|
This will upload a new, fixed build to the same `internal` track. Repeat this process until the build is stable.
|
|
|
|
### 3. Promoting to the Next Track
|
|
Once you are confident that a build is stable, you can "promote" it to a wider audience by tagging the **exact same commit** for the next track.
|
|
|
|
```bash
|
|
# The commit tagged as v2.3.5-internal.2 is stable and ready for the "Closed" track
|
|
git tag v2.3.5-closed.1
|
|
git push origin v2.3.5-closed.1
|
|
```
|
|
This triggers the workflow again, but this time it will send the build to the `NewAlpha` track for your closed testers. You can then continue the cycle of testing, fixing, and promoting all the way to production.
|
|
|
|
### 4. Finalizing the Release
|
|
After the final production release is complete and verified, open a Pull Request to merge the release branch back into `main`. This ensures any hotfixes applied during the release cycle are properly reviewed and integrated.
|
|
|
|
* **Title:** `Release/2.3.5`
|
|
* **Base Branch:** `main`
|
|
* **Compare Branch:** `release/2.3.5`
|
|
|
|
Once the PR is approved and merged, you can safely delete the release branch.
|
|
|
|
## Manual Finalization Steps
|
|
|
|
### For Internal Releases
|
|
|
|
* **Automated Action:** The AAB is uploaded to the `internal` track and is **rolled out to 100% of testers automatically**.
|
|
* **Your Manual Step:**
|
|
1. **Verify the build** in the Google Play Console and with your internal testers.
|
|
|
|
### For Closed Releases
|
|
|
|
* **Automated Action:** The AAB is uploaded to the `NewAlpha` track and is **rolled out to 100% of testers automatically**.
|
|
* **Your Manual Step:**
|
|
1. **Verify the build** in the Google Play Console and with your closed track testers.
|
|
|
|
### For Open Releases
|
|
|
|
* **Automated Action:** The AAB is uploaded to the `beta` track and begins a **staged rollout to 25% of your open track testers automatically**.
|
|
* **Your Manual Steps:**
|
|
1. **Verify the build** in the Google Play Console.
|
|
2. **(Optional)** Go to the GitHub "Releases" page, find the **draft release**, and publish it so your open track testers can see the official release notes.
|
|
|
|
### For Production Releases
|
|
|
|
* **Automated Action:**
|
|
* The AAB is uploaded to the `production` track in a **draft** state. It is **not** rolled out to any users.
|
|
* A corresponding **draft** release is created on GitHub with all build artifacts.
|
|
* **Your Manual Steps:**
|
|
1. **Publish on GitHub First:** Go to the GitHub "Releases" page and find the draft. Review the release notes and artifacts, then **Publish release**. This makes the release notes publicly visible.
|
|
2. **Promote on Google Play Second:** *After* publishing on GitHub, go to your Google Play Console. Find the draft release, review it, and then proceed to **start the rollout to production**.
|
|
|
|
## Monitoring the Release
|
|
|
|
After a release has been rolled out to users (especially for Open and Production), it is crucial to monitor its performance.
|
|
|
|
* **Google Play Console:** Keep a close eye on the **Vitals** section for your app. Pay special attention to the crash rate and ANR (Application Not Responding) rate. A sudden spike in these numbers is a strong indicator of a problem.
|
|
* **Datadog:** Check your Datadog dashboards for any unusual trends or new errors that may have been introduced with the release.
|
|
* **Crashlytics:** Review crash reports in Firebase Crashlytics to identify any new issues that users may be experiencing.
|
|
* **User Reviews:** Monitor user reviews on the Google Play Store for any negative feedback or reports of bugs.
|
|
* **Community Feedback:** Monitor Discord, GitHub Issues, and community forums for feedback from users who have received the update.
|
|
|
|
If you identify a critical issue, be prepared to halt the rollout in the Google Play Console and tag a new, fixed version.
|