The process of releasing a new change to your Android app is time-consuming — but before you even get to that stage, you’ll want to make sure your app has gone through sufficient testing. Software development practices such as continuous integration and continuous delivery help you reduce cycle times for delivering new changes by introducing automation for building, testing, and deploying your app.
In this guide, I will discuss how to migrate your Android app to Bitrise, covering the following steps:
- Building your Android app
- Running unit tests
- Signing your APK
- Running instrumentation tests on the cloud using Firebase Test Lab
- Distributing your app to testers using Firebase App Distribution
- Deploying your signed APK into production through the Google Play Console
Before you get started
Before we get started with this article, let’s assume that your Jenkins server is already configured for the Android app with the following settings:
1. Installed and configured the Environment Variables for the following:
- Java JDK > JAVA_HOME (The path to the Java JDK on your local machine)
- Android SDK > ANDROID_HOME (The path to the Android SDK on your local machine)
- Gradle > GRADLE_HOME (The path to the Gradle user home directory on your local machine)
- Git > The path to Git executable
2. Installed additional Jenkins Plugins:
- Android Signing Plugin
- Google Play Android Publisher Plugin
3. Have a Firebase Android Project with Google Service Account JSON file.
4. Have a Google Cloud Service Account and enabled access to Google APIs, which we will use for testing.
5. Installed gcloud command line for Firebase Test Lab and App Distribution.
6. Configured Google Play Console API Access Credentials to upload Android AAB/APKs to Google Play.
Then you should have a Jenkins pipeline project that includes the Jenkinsfile with the following setup:
And the final pipeline should look like this:
As you can see, setting up an Android project with Jenkins has a lot of steps, including server configuration, installing plugins, and writing the Jenkinsfile from scratch using Groovy code, which requires additional skills with Groovy programming languages. You will also need some help from the DevOps team to install and configure Jenkins.
Migrating an Android app from Jenkins to Bitrise
Now it’s time to speed your CI/CD pipeline with easier setup and less effort. Let’s get started by migrating our Android app from Jenkins to Bitrise:
1. First, you need to create a new Bitrise account (it’s free). You can use your email or any other account name you prefer.
2. After logging in, you will have an empty dashboard where you can start adding your projects.
3. Click on the Add your first app button!
4. Select your account and in the SET THE PRIVACY OF THE APP section select Private or Public), then click Next.
5. Give Bitrise access rights to your source code provider and choose the repository.
6. Now you need to set up the repository access: click on auto-add SSH key or add your SSH key.
7- Choose Branch name,for example, master and click Next.
8. After this, Bitrise will run a validation with your repository and configuration.
9. After validating, the project build configuration will display successfully (for example,Android App).
10. Click on the Confirm button after reviewing the Workflow stack. You can add an app icon as well.
11. The final step is the Webhook setup. We just need to click on Register a Webhook for me! button and you will trigger your first Android build for your project 🚀 🎉
12. You will be redirected to the build log where you can check the Steps and the build status.
13. At the end, you will find a summary of all the tasks you ran during the build and how much time they took, along with the Step names. You can download logs or check the apps and artifacts here.
You will also receive an email notification about the build status.
NOTE: As you may have noticed, we didn’t need to configure anything related to the infrastructure or the stack. Bitrise is managing all of these things for you, for example install and configure Java, Android SDK, Gradle, or Git.
14. Now let’s open the Workflow Editor to start migrating all the required steps that we have in the Jenkinsfile.
15. In the Workflow Editor, you will find a predefined set of Steps.
Let’s remember the steps we need to take for the migration:
- Clone Repository
- Configure Google Service Account
- Build an app
- Release an app
- Sign an app
- Config Google Cloud Project
- Run UI tests on FireBase TestLab
- App Distribution
- Upload Android Apk to the Google
- Send Slack notification
- Send email notification
First, I will start by adding the Google Service Account JSON file and the Keystore for signing the app as secrets.
16. Click on the Code Signing tab from where you can upload the Signing key and the Google Service Account JSON file as the following images show:
17. Click on the Secrets tab to add your Environment Variables (Env Vars), such as Google Cloud Project Name, Service Account file location, and Google Application.
18. Click on the Env Vars Tab to add any other Env Vars you need in your app.
Note: DO NOT add private information here! These Env Vars will also be available in builds triggered by pull requests and the bitrise.yml.
19. Click on the Workflow Editor Tab to start adding the missing Steps into your CI/CD Workflow.
TIP: You can rename the Workflow default name from primary to, for example, Android CI/CD.
20. We already have a Step for the Active SSH Key and Git Clone Repository to access and clone the source code from GitHub or any other source code management tool.
21. We also have the Bitrise.io Cache:Pull Step which helps us download the build cache from bitrise.io, and move the files back to their original place. The aim is to speed up your builds — not having to download every single dependency every time can be a serious timesaver.
22. You can add a new Step by clicking on the [+] button, which will display all the integrations we have for Android applications in Bitrise.
23. Search for the File Downloader Step and add it after the Bitrise.io Cache:Pull Step.
24. You can rename the File Downloader Step to Download Google Service Account JSON, add the path of the file from the Env Vars and save changes.
TIP: Bitrise has a Step library of 320+ integrations for all the mobile platforms. We’re sure you’ll find what you need. :)
25. Add another Script Step to save Google Service Account JSON.
26. We already have a Step for Installing missing Android SDK components so you can leave it.
27. There’s another Step, Android Lint for running the lint against the application to check the code format.
28. Add the Android Unit Test Step and configure the Module and the Variant inputs.
29. Add a new Android Build Step to build the application for release.
30. Add the Android Sign Step to sign the app. You can easily configure the setup. Before that, you should sign your app.
The output of this Step will be the .apk and the .aab files.
31. To run UI tests on Firebase Test Labs with virtual or physical devices from Bitrise, you have different choices. You can use the Virtual Device Testing Step that internally connects with Firebase Test Lab, uploads your APKs, and collects the results to the Test Report Add-on. You can also specify which test type you need, such as instrumentation, Robo, or Game loop from the Step’s configuration.
You can find the test results under the Test Reports add-on with all the information you need.
TIP: If you have a Firebase project and Google Cloud project you can even use the Flank Step to run parallel UI tests to reduce the build time. Find more information in this video.
32. You can also use the Change Android versionCode and versionName Step before distributing it.
33. Then you’ll need to distribute the application by using Firebase and taking these steps:
- Upload your app for distribution in Firebase App Distribution from Jenkins.
- Automate an email notification to testers to try out the app.
- Try the app you’ve built using the App Tester app for Android.
34. Add the Google Play Deploy Step. You can configure the release track, user fraction, status, and the name of the release.35. Finally, add this Step to send notifications about build statuses to the team. Remember to configure the webhook and the slack API Token first. 35. Finally, add this Step to send notifications about build statuses to the team. Remember to configure the webhook and the slack API Token first.
35. Finally, add this Step to send notifications about build statuses to the team. Remember to configure the webhook and the slack API Token first.TIP: For each Step in the Bitrise Workflow, you have the option to run the current Step — whether the previous Step failed or not — which will allow you to abort the build in case any of the previous Steps failed. By default, it’s set to No.TIP: For each Step in the Bitrise Workflow, you have the option to run the current Step — whether the previous Step failed or not — which will allow you to abort the build in case any of the previous Steps failed. By default, it’s set to No.
TIP: For each Step in the Bitrise Workflow, you have the option to run the current Step — whether the previous Step failed or not — which will allow you to abort the build in case any of the previous Steps failed. By default, it’s set to No.36. You can now run your Android Workflow manually by clicking Start/Schedule a Build. Via the trigger map, you can specify the GitHub Tag or branch of a specific Workflow.
36. You can now run your Android Workflow manually by clicking Start/Schedule a Build. Via the trigger map, you can specify the GitHub Tag or branch of a specific Workflow.TIP: If you want to schedule nightly builds, you can also configure it easily by selecting the date/time, branch name, and the Workflow’s name.
TIP: If you want to schedule nightly builds, you can also configure it easily by selecting the date/time, branch name, and the Workflow’s name.
TIP: You can find the bitrise.yml file with all the Steps that you’ve added in the Workflow Editor and save it in your repository or leave it on the platform. TIP: If the Android team is scaling and you need to reduce build times, you can run parallel builds with different sub Workflows. TIP: If the Android team is scaling and you need to reduce build times, you can run parallel builds with different sub Workflows.
TIP: If the Android team is scaling and you need to reduce build times, you can run parallel builds with different sub Workflows.
Check out the Bitrise Start Build or this article about how you can fan out your builds.
Congratulations! 🎉You have successfully migrated your Android app from Jenkins to Bitrise. You can now start building and releasing your applications seamlessly, with no extra effort.
I hope you found this article useful. For even more information, you can visit our detailed migration guide on Devcenter or check out our Jenkins vs. Bitrise page comparing the main features of the two tools.
If you have any questions, feel free to contact us on our Twitter or via email. If you’d like to find out more about how Bitrise can help you release better apps, faster, you can also request a demo here.
.jpg)
.jpg)
