CI/CD: GitHub Actions pipeline for testing, building, and deploying to all platforms

[Spaccesi]

Summary

Set up a full CI/CD pipeline using GitHub Actions to automate testing, building, and releasing the Flutter app across all supported platforms: iOS, Android, Web, macOS, Windows, and Linux. The pipeline should also prepare the repository structure with the necessary secrets, configurations, and workflow files.

---

Platforms & Target Stores

Platform	Store / Distribution
Android	Google Play Store (Internal → Production)
iOS	Apple App Store (TestFlight → Production)
Web	Firebase Hosting / GitHub Pages
macOS	Mac App Store / Direct DMG release
Windows	Microsoft Store / GitHub Releases (.msix)
Linux	Snap Store, Flatpak, or GitHub Releases (.deb / AppImage)

---

Proposed Workflow Structure

.github/
└── workflows/
    ├── test.yml          # Run on every PR and push to main
    ├── build.yml         # Build all platforms on tag/release
    ├── deploy_android.yml
    ├── deploy_ios.yml
    ├── deploy_web.yml
    ├── deploy_macos.yml
    ├── deploy_windows.yml
    └── deploy_linux.yml

---

Workflow Details

🧪 test.yml — Continuous Testing

Triggers on: every push and pull request to main / develop

• Flutter analyze (static analysis)
• Flutter test (unit + widget tests)
• Code coverage report (upload to Codecov or similar)
• Fail fast on any error

🤖 deploy_android.yml

• Build .aab (Android App Bundle) in release mode
• Sign with keystore stored in GitHub Secrets
• Upload to Google Play via r0adkll/upload-google-play action
• Tracks: internal on develop, production on main

🍎 deploy_ios.yml

• Build .ipa using xcodebuild on macos-latest runner
• Sign with Apple certificate + provisioning profile stored in Secrets
• Upload to TestFlight via Apple-Actions/upload-testflight-build or fastlane
• Promote to App Store manually or via second job

🌐 deploy_web.yml

• Build Flutter Web (flutter build web --release)
• Deploy to Firebase Hosting or GitHub Pages
• Preview deployments on PRs (Firebase preview channels)

🖥 deploy_macos.yml

• Build .app bundle on macos-latest runner
• Notarize with Apple credentials
• Upload to Mac App Store or attach .dmg to GitHub Release

🪟 deploy_windows.yml

• Build .msix on windows-latest runner
• Sign with code-signing certificate
• Publish to Microsoft Store via microsoft/store-submission or attach to GitHub Release

🐧 deploy_linux.yml

• Build on ubuntu-latest runner
• Package as .deb, .AppImage, and/or Snap
• Publish to Snap Store (snapcore/action-publish) or attach to GitHub Release

---

Repository Preparation

Required GitHub Secrets

# Android
ANDROID_KEYSTORE_BASE64
ANDROID_KEY_ALIAS
ANDROID_KEY_PASSWORD
ANDROID_STORE_PASSWORD
GOOGLE_PLAY_SERVICE_ACCOUNT_JSON

# iOS / macOS
APPLE_CERTIFICATE_BASE64
APPLE_CERTIFICATE_PASSWORD
APPLE_PROVISIONING_PROFILE_BASE64
APPLE_TEAM_ID
APP_STORE_CONNECT_API_KEY_ID
APP_STORE_CONNECT_API_ISSUER_ID
APP_STORE_CONNECT_API_KEY_BASE64

# Web
FIREBASE_TOKEN  (or FIREBASE_SERVICE_ACCOUNT)

# Windows
WINDOWS_CERTIFICATE_BASE64
WINDOWS_CERTIFICATE_PASSWORD
MS_STORE_TENANT_ID
MS_STORE_CLIENT_ID
MS_STORE_CLIENT_SECRET
MS_STORE_APP_ID

# Snap (Linux)
SNAPCRAFT_STORE_CREDENTIALS

Branch & Tag Strategy

• develop → deploys to all staging/beta tracks
• main → deploys to all production tracks
• Tags v*.*.* → triggers GitHub Release + attaches binaries

Additional Repo Setup

• Add .github/dependabot.yml to keep Actions and Flutter deps up to date
• Add status badges to README.md for each platform build
• Add CONTRIBUTING.md with branch naming and PR conventions
• Configure branch protection rules on main and develop (require passing CI)

---

Possible Solution / Tools

• fastlane for iOS/Android signing and upload automation
• flutter-action for Flutter SDK setup
• upload-google-play for Android
• snapcore/action-publish for Linux Snap
• Firebase CLI for Web deployments
• GitHub Environments with manual approval gates for production deploys

---

Acceptance Criteria

• test.yml runs on every PR; PRs cannot be merged if tests fail.
• Each platform has a dedicated deploy workflow triggered on push to main or a v* tag.
• Android builds and uploads an .aab to Google Play (internal track on develop, production on main).
• iOS builds and uploads to TestFlight on develop; promotes to App Store on main.
• Web builds and deploys to hosting; PRs generate preview URLs.
• macOS build produces a notarized .dmg and/or publishes to Mac App Store.
• Windows build produces a signed .msix and publishes to Microsoft Store or GitHub Releases.
• Linux build produces .deb / AppImage / Snap and uploads to Snap Store or GitHub Releases.
• All secrets are documented in the repo wiki or CONTRIBUTING.md.
• Branch protection is configured: main requires passing CI and at least one review.
• README.md includes CI/CD status badges for all platforms.