-
Notifications
You must be signed in to change notification settings - Fork 3
Android App Deployment (EN)
Not much. Currently, the deployment of the beta version is done automatically by Travis-CI and Gradle Play Publisher. The release process starts when a commit is made on master.
Even though the process is automated, human intervention is still and only needed to update the release notes and the screenshots published on the Play Store. The app's release notes are stored here. Before committing on master, the release notes should be changed. If not, the previous release notes will be used.
Here are the steps done by Gradle Play Publisher and Travis-CI to release the beta version:
The process starts when a commit is made to master.
A build is normally run by Travis according the travis.yml file. If the build succeeded, Travis will also execute the deploy block which simply execute the deploy_beta.sh script.
Since the source code is open-source, some files have been encrypted because they need to be kept secret. During a build, Travis will decrypt them and place them where to need to be.
The deploy_beta.sh script will run the publishBetaReleaseApk Gradle command which will deploy the beta version of the app on the Play Store. After a moment, the update should be available to the users.
If your are not familiar with Travis, you should take a look at their doc here.
The travis.yml configuration file is located here. Since the repo also contains the iOS app, a matrix has been specified to run a job for Android and another job for iOS.
Moreoever, during the process, Travis will decrypt secret files. The passwords are stored as encrypted environment variables.
Before an app can be released to the Play Store, it needs to be signed. For more information, take a look at the official doc here. This project make use of App Signing by Google Play which let Google manages our signing key for us. We simply need to sign our app with an upload key. This key is stored in a keystore called etsm_upload_ks.jks. The encrypted version is stored here.
Furthermore, the signing information have been removed from the build files since they are sensitive information. Take a look here to know how it has been done. To summarize briefly, the signing configuration in the app module build.gradle refers to properties stored in file called keystore.properties. The encrypted version of this file is located here.
Gradle Play Publisher is a Gradle plugin that let you upload your app and other details to the Play Store. Please start by reading through their doc here.
In this project, the configuration for Gradle Play Publisher is done in the app module's build.gradle file.
At the moment, Gradle Play Publisher has only set been for the beta flavor.
You shouln't have to deploy manually, but if needed, here are to steps for deploying the app without relying on Travis CI or Gradle Play Publisher :
- In order to start, you need to have access to the encrypted files's passwords. They are kept by App|ETS because only members should be able to access them. Furthermore, you also need to have access to the app on the university's Play Store account.
- Decrypt the files and move each file to the right directory. Check the travis.yml file and the script to know how it is done. You should be aware that if you enter the passwords on the command line, someone could look at your terminal window history or list of running processes, get the password, and then have access to password that you have typed.
- Bump the
versionCode. It should be higher than theversionCodeof the last APK uploaded otherwise the new APK will be refused. - Next, you need to tell Android Studio to generate a signed APK. Follow the official instructions here.
- Publish the APK on the Play Store. Follow the instructions here to know how.
At the moment, nothing have been configured to automate the deployment process of the production version.
How it was done for the second version of ÉTSMobile
First of all, the things described above was done manually. For example, API keys was set manually and files such as google-services.json was added manually.
Moreover, the members of App|ETS wasn't allowed to deploy the production version to the Play Store. To do so, an email has to be sent to a member of the sTI which are the IT staff of the university. They own the Google Play account and manage various web services from which the app fetches its content from. The email sent would include details such as the release notes and the APK.
Even though App|ETS members are not allowed to deploy the production version, the process can still be automated. Here are some ideas below:
In the deploy block of the Travis configuration, check for a tag. If the condition is verified, build the production version of the app in release mode. Check here to know to do it from the command line.
Then, an email would be built and sent automatically. The email would contains the releases notes and the APK file. If the APK couldn't attached to the email, it would be possible to upload the file to storage service such as Amazon S3 beforehand and include a link to the APK file in the email.
Use fastlane
Gradle Play Publisher could be replaced by fastlane. It's an open-source platform that let developers automate their release process for their Android and iOS apps.
It seems that it would possible to configure an action that send an custom email with an attachment. For more information, check here.
During the development of the beta version, even though fastlane was considered initially, Gradle Play Publisher was chosen instead because fastlane seemed to be more aimed toward iOS developers. For example, the first step of the setup guide tells the user to install Xcode. However, most members don't have a macOS device and it would be impossible for them to configure fastlane.