Continuous Delivery for Android Using GitHub Actions
Learn how to create a continuous delivery pipeline in Android to deploy your apps to the Google Play Store. By Subhrajyoti Sen.
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Contents
Continuous Delivery for Android Using GitHub Actions
30 mins
- Getting Started
- Using GitHub Actions
- Uploading the Project to GitHub
- Creating a Workflow
- Running the Tests
- Generating a Signed Release Build
- Creating a Keystore
- Storing Secrets
- Signing the Build
- Triggering a Release
- Pushing a Version Tag
- Pull Request to Master
- Preventing a Merge if Tests Fail
- Deploying to Firebase App Distribution
- Setting up Firebase
- Adding Testers
- Fetching the App ID and Token
- Upload to Firebase Action
- Visualizing a Workflow
- Deploying to Play Store
- Setting up a Service Account
- Upload the Google Play Action
- Where to Go From Here?
Upload the Google Play Action
To upload a build to the Play Store Console, use the r0adkll/upload-google-play action. You want to deploy to the Play Store only when you merge a pull request to the master branch. To do this, create a new file named play_store_workflow.yml in .github/workflows and add the following to it:
name: Deploy to Play Store
on:
push:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Generate Release APK
run: ./gradlew assembleRelease
- name: Sign APK
uses: r0adkll/sign-android-release@v1
# ID used to access action output
id: sign_app
with:
releaseDirectory: app/build/outputs/apk/release
signingKeyBase64: ${{ secrets.SIGNING_KEY }}
alias: ${{ secrets.ALIAS }}
keyStorePassword: ${{ secrets.KEY_STORE_PASSWORD }}
keyPassword: ${{ secrets.KEY_PASSWORD }}
- uses: actions/upload-artifact@master
with:
name: release.apk
path: ${{steps.sign_app.outputs.signedReleaseFile}}
- uses: actions/upload-artifact@master
with:
name: mapping.txt
path: app/build/outputs/mapping/release/mapping.txt
deploy-play-store:
needs: [build]
runs-on: ubuntu-latest
steps:
# 1
- uses: actions/download-artifact@master
with:
name: release.apk
- uses: actions/download-artifact@master
with:
name: mapping.txt
# 2
- name: Publish to Play Store internal test track
uses: r0adkll/upload-google-play@v1
with:
serviceAccountJsonPlainText: ${{ secrets.SERVICE_ACCOUNT_JSON }}
# 3
packageName: com.raywenderlich.android.rwquotes
releaseFile: app-release-unsigned-signed.apk
track: internal
userFraction: 0.50
mappingFile: mapping.txt
The workflow above triggers when you push any change to the master branch. The build job is the same as the one you used in the previous workflow.
The deploy-play-store job does the following:
- Downloads the release APK and mapping file using the actions/download-artifact action.
- Uploads the APK to the internal track and makes it available to 50% percent of the users on that track.
- Specifies the package name of the app and also the APK and mapping file to upload.
Commit this file and push it to GitHub. To verify the workflow, push an empty commit to the master branch. Once the workflow is complete, visit the Internal track on the Google Play Console. You'll see that a build of the app has published, as shown below:
If you get an error stating that the package name is already in use on the Play Store, open app/build.gradle and change the applicationId
to something specific to your project. Additionally, remember to register a new app on Firebase App Distribution and update the package name in the action as well.
Congratulations, you've successfully built a complete continuous delivery pipeline using GitHub Actions.
Where to Go From Here?
You can download the completed project files by clicking the Download Materials button at the top or bottom of the tutorial.
There are many variations of the continuous delivery process, which lets you modify it to adapt to your team's processes. For example, instead of deploying to the internal track when changes are pushed to GitHub, you could deploy it to the production track.
You can also try creating a workflow that extracts the changelog from a commit message and attaches it while deploying the build. Use the changelog either in the Release notes section on Firebase App Distribution or the What's new section of the Play Console releases.
The possibilities with GitHub Actions are vast and you can continue tweaking the workflows till you get something that completely automates your actual workflow of testing and deploying.
If you have any questions or comments, please join the forum discussion below.