Release management · Android · DevOps

From git push to Google Play: The Full Android Release Lifecycle, Told by the Release Manager 🚀

Writing the code is the middle of the story. Before it there is a pull request, and after it there is a release branch, a build server, a handful of testers, three Google Play tracks, a rollout slider, and a message to everyone who cares. I have been the person holding the release button for a long time, and I love it: it is the moment where weeks of work meet real people. This is the whole journey, stage by stage, with who watches what, what breaks, and how to tell the team when it is done.

1. The cast

A release is a team sport. Here is who is on the field. Notice how many of them are not developers.

2. The road map

Eight stations from an idea in a branch to a happy user. Different companies rename them, merge them or skip one, but I have never seen a healthy release that had none of them.

3. Stage 1–2: Pull request and merge

4. Stage 3: Cut the release branch

5. Stage 4: CI builds the release candidate

6. Stage 5: Testers get the build

7. Stage 6: Google Play, internal to closed

8. Stage 7: Staged rollout to the market

9. Stage 8: Announce, watch, close

What I send, and to whom

10. Who watches what

The most common release failure I see is not a bug. It is nobody knowing they were supposed to be watching. I put this table on the wiki.

For the DevOps column, the tools and install guides are in The Android DevOps Toolbox.

11. The pipeline as code

A sketch of a GitHub Actions release workflow. CircleCI and Bitrise express the same steps in config.yml or bitrise.yml. Treat action names and versions as placeholders and copy current ones from each action’s documentation.

name: release
on:
  push:
    branches: ["release/**"]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<version>
      - uses: actions/setup-java@<version>
        with: { distribution: temurin, java-version: "<jdk>" }
      - uses: gradle/actions/setup-gradle@<version>

      - name: Test
        run: ./gradlew lintRelease testReleaseUnitTest

      - name: Decode keystore
        run: echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 -d > "$RUNNER_TEMP/release.jks"

      - name: Build signed bundle
        run: ./gradlew bundleRelease -PversionCode=${{ github.run_number }}
        env:
          KEYSTORE_PATH: ${{ runner.temp }}/release.jks
          KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
          KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
          KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}

      - uses: actions/upload-artifact@<version>
        with:
          name: release-bundle
          path: |
            app/build/outputs/bundle/release/*.aab
            app/build/outputs/mapping/release/mapping.txt

  distribute-testers:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@<version>
      # upload to Firebase App Distribution (Firebase CLI or a maintained action)
      # or to DeployGate (its API or CLI), then post the link to the team channel

  play-internal:
    needs: distribute-testers
    environment: play-internal        # protected environment: needs a human approval
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@<version>
      # upload the same .aab to the Play internal track with a service account
      # (fastlane supply, Gradle Play Publisher or a maintained action)

• A protected environment turns “send to Play” into a deliberate, logged human approval.
• Secrets live in the CI vault, never in the repo. Rotate them when a person with access leaves.
• Mask logs. A keystore password printed in a build log is a security incident.

12. When it goes wrong: the hotfix lane

The lane is the same pipeline with fewer steps, never a different, unreviewed one. Keep a tested hotfix procedure written down, and practice it once a quarter in a quiet week.

13. Every company is different, and yet…

I have seen very different cadences. They are policies layered on the same skeleton.

14. Release-day runbook and classic oops moments

15. Takeaways and glossary

• A release is a pipeline of small gates, not one heroic push.
• Build once, sign once, promote the same bundle through testers, Play tracks and production.
• Release branches give you a quiet room to stabilize; staged rollout gives you a brake in the market.
• Assign a named owner and a stop rule to every stage; write them down.
• Close the loop: tag, merge back, announce, and watch for a day or two.

Links and further reading

• Play Console: open, closed and internal tests · Staged rollouts · Android App Bundle
• Firebase App Distribution · DeployGate docs · GitHub Actions · CircleCI · Bitrise
• On this site: The Android DevOps Toolbox · Release validation strategy · Git branching guide · App Distribution overview · Crashlytics