Builder's Log: Our Flutter App Release Pipeline and CI/CD

As indie developers, automating releases is crucial. Here's an inside look at how we build, test, and deploy our Flutter app (currently Android-only), ensuring quick iteration with quality.

Continuous Integration with GitHub Actions

We use GitHub Actions as our CI platform. Every push to main triggers a workflow (.github/workflows/ci.yml). The steps are:

1. Checkout code: We fetch the repository.
2. Set up Flutter: Use the subosito/flutter-action to install Flutter 3.44. This caches the SDK to speed up future runs.
3. Dart/Flutter analysis: Run flutter analyze to catch errors and dart format to enforce style. This enforces code quality across the team.
4. Unit tests: Execute flutter test. We have a suite covering ~80% of our Dart code. Passing these ensures basic functionality.
5. Build APK: Run flutter build apk --release --split-per-abi. This produces APKs for arm64 and x86. We split ABI to reduce APK size for users. Build takes ~4 minutes on our runner (with cached Gradle).
6. Artifact upload: We save the APKs to the workflow artifacts (for review) and also mark the output.

This CI pipeline prevents us from merging bad code into main. On average, builds succeed 97% of the time; the failures were usually flaky device tests or outdated pub dependencies, which we fixed.

Automated Deployment to Google Play

After a successful build, we use a second job to deploy:

• Action used: r0adkll/upload-google-play (a popular GH Action for Play Store).
• Process: We created a Google service account with "Release Manager" role, downloaded its JSON key, and encrypted it in our repo secrets. The action logs in with that and uploads the APKs.
• Track: We upload to the internal testing track first, so QA folks and us can try it before public release.
• Release notes: As a team, we wrote a script to auto-generate release notes. It pulls the merged PR titles since last release and passes them to an AI model (GPT-4) with a prompt: "Write user-friendly release notes from these bullet points." The AI produces a draft which we paste into Play Console. This saves hours of writing.

On average, from code merge to published internal build is ~10 minutes (including build time and upload). Public release (to 10% of users, then 50%, then 100%) takes a few more days, but initial rollout is fast.

Metrics and Observations

Tracking performance of our releases:

• Crash Rate: We monitor Google Play's pre-launch reports and have integrated Crashlytics. After adopting CI with tests, our crash-free sessions jumped from ~95% to ~99% over a few releases. The last release had a crash rate of only 0.15% (goal is <0.5%). We credit automated tests catching a NullPointer bug and consistent signing handling.
• Build Time: Initially CI builds took ~7 minutes. By caching Flutter and Gradle, plus splitting ABIs, we cut it to ~4 minutes per run. Fast builds mean quick feedback on PRs.
• APK Size: With split-per-abi and enabling R8 minification, our APKs are now under 15MB for arm64. Users appreciate faster downloads, especially on mobile data.

Future Plans

We plan to add an iOS pipeline (likely with Codemagic or GitHub Actions on macOS runners, since signing is needed). For now, Android is our focus, but once we start iOS, we'll likely mirror the process there.

We also want to integrate end-to-end tests using Flutter integration_test, but we're still sorting out reliable device emulation in CI. That's a goal for the next months.

Overall, this automated pipeline lets us release frequently and confidently. We can ship hotfixes within hours if needed, and teams outside can just review code, knowing that testing and deployment happen seamlessly. For indie developers reading this: even a small app benefits immensely from automation. It prevents regressions and frees you to focus on features, not on pressing "Build" manually each time.