Travis CI recently purchased Travis CI for a fee. Travis CI has an interesting charging model, not by project or user, but by work process. For example, the initial version is $129/ month, providing 2 work processes. In addition to running unit tests, I wanted to take full advantage of the limited number of projects, so I took the time to build an Android automatic publishing workflow based on Travis CI.

Before android development was automated, there was always a workflow like this:

  1. Develop some new features and commit code
  2. After completing some of the features, package a beta version of APK
  3. Upload the beta version of APK to QQ group/network disk/Fir. Im/dandelion etc
  4. Explain the features of the current version in the QQ group or distribution platform
  5. Notify the tester to test

With this automated publishing, the workflow is simplified to:

  1. Develop new features and submit code
  2. throughgit tagTag a beta version of the code, in the description of the tag to write the currently completed functionality

After the Tag is submitted, Travis CI will automatically compile the code, generate an APK file and distribute it to Github and fir.im. The Tag description will be kept in Github and fir.im, and an email will be sent to all participants when the distribution is complete. As a developer, you just need to focus on tagging the code.

The process may seem like a lot of work, but the Travis CI is just a few lines of instructions, one by one:

Enable Travis CI for android projects

Travis CI is probably one of the best continuous integration services available today and can be easily turned on if the code base is based on Github. Since this article covers many of the basic concepts of Travis CI, it is recommended that you first take a look at the Custom Build section of Travis CI.

I wrote a long time ago about using Travis CI in PHP projects when I introduced continuous integration for PHP projects. For Android projects, the steps are almost the same:

First, prepare a.travis. Yml file in the root directory of the Android project. The.travis.

language: android sudo: false android: components: -build-tools-23.0.1 -android-23 -extra-android-m2repository -extra-android-support script: - "./gradlew assembleRelease"Copy the code

As you can see from the above configuration without reading the documentation, we are running an Android project, android SDK version 23, and the project will use BuildTools version 23.0.1. We have also introduced some necessary components to build this project. Support Library (extra-Android-support), Android Support Repository (extra-Android-m2Repository), etc.

When Travis CI is ready with the environment we need, it will automatically run the commands set in the script part of the YML file./gradlew assembleRelease, Build /outputs/ APk /app-release.apk will be generated in the main module of the project if it runs successfully.

Finally, go to the Travis CI home page and log in directly using the Github account that has the project Admin permission. Select the project to enable Travis CI and set the right switch to On.

Travis CI currently has two websites: travis-ci.org for open source projects and Travis-ci.com for private paid projects. The interface and operation of the two sites are almost identical except for the domain name.

There is also a sudo: false line in the configuration to enable the Travis CI container-based task for more efficient compilation.

Android automates building password and certificate security

Android projects require a certificate file and several passwords to distribute, but whether open source or private, the original certificate or password should never be put into a code base (in principle, certificates and passwords should not be handed over to the developer, but should only be compiled through the distribution server). Travis CI provides two solutions for this. One is to symmetrically encrypt sensitive information, passwords, certificates, etc., and decrypt them when CI builds the environment, and the other is to set passwords, etc., as environment variables at build time through Travis CI’s console (i.e. website).

Since the former generates a pair of environment variables on the Travis console, I try to choose the latter, but since the Travis console cannot upload files, I have to choose the former when it comes to file encryption.

The build.gradle file for your project might look something like this if you don’t care about security:

android { signingConfigs { releaseConfig { storeFile file(".. /keys/evandroid.jks") storePassword "123456" keyAlias "evandroid_alias" keyPassword "654321" } } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' signingConfig signingConfigs.releaseConfig } } }Copy the code

In Travis CI, you can set Environment Variables by clicking on the project name -> Settings -> Environment Variables. For example, we can set KEYSTORE_PASS, ALIAS_NAME, and ALIAS_PASS for the above configuration. In Travis CI, we can obtain these environment variables through system.getenv ().

In a local development environment, I add these variables to the gradle.properties file so that they can be used directly within build.gradle. Below is gradle.properties for the development environment

KEYSTORE_PASS=123456
ALIAS_NAME=evandroid_alias
ALIAS_PASS=654321
Copy the code

So build. Gradle becomes build.gradle

releaseConfig { storeFile file(".. /keys/evandroid.jks") storePassword project.hasProperty("KEYSTORE_PASS") ? KEYSTORE_PASS : System.getenv("KEYSTORE_PASS") keyAlias project.hasProperty("ALIAS_NAME") ? ALIAS_NAME : System.getenv("ALIAS_NAME") keyPassword project.hasProperty("ALIAS_PASS") ? ALIAS_PASS : System.getenv("ALIAS_PASS") }Copy the code

Next, the certificate files are processed. To facilitate features such as file encryption, Travis CI provides a Ruby-based CLI tool that can be installed directly using gem

gem install travis
Copy the code

After the installation, enter the root directory of the Android project and try to encrypt the certificate file:

travis encrypt-file keys/evandroid.jks --add
Copy the code

If you run it for the first time, Travis will prompt you to login. Run Travis login –org and enter the Github username and password. (Travis Login — Pro is the paid version)

The Travis encrypt-file directive does several things:

  1. The Travis CI console automatically generates a pair of keys like:encrypted_e41864bb9dab_key.encrypted_e41864bb9dab_iv
  2. Pass by keyopensslEncrypt the file, which is generated in the project root directory in the example aboveevandroid.jks.encfile
  3. in.travis.ymlTo automatically generate the configuration of decrypted files in Travis CI environment, as can be seen after the above example.travis.ymlA few lines too many:
before_install:
- openssl aes-256-cbc -K $encrypted_e41864bb9dab_key -iv $encrypted_e41864bb9dab_i -in keys/evandroid.jks.enc -out keys/evandroid.jks -d
Copy the code

Travis CI runs in the project root directory by default, so adjust the path of the ENC file as required.

Finally, don’t forget to ignore keys/evandroid.jks and gradle.properties in.gitignore and delete them from the code base.

Travis CI automatically publishes Android APK files to Github Release

Once the Script part of the Travis CI runs successfully, it is ready to go to the release phase through the configuration file. Here is an example of a Travis CI release:

deploy:
  provider: releases
  user: "GITHUB USERNAME"
  password: "GITHUB PASSWORD"
  file: app/build/outputs/apk/app-release.apk
  skip_cleanup: true
  on:
    tags: true
Copy the code

This example configures something like this:

  • providerIn addition to Github, Travis CI also supports publishing to AWS, Google App Engine, and dozens moreprovider
  • Github username and password, because Travis CI is uploading APK files, it needs to have write permission for the Github project
  • file: To publish a file, enter the file path
  • skip_cleanup: By default Travis CI clears all generated files after compilation is complete, so theskip_cleanupSet to true to ignore this action.
  • on: Release time, set totags: true, that is, only when there istagIn the case of the release.

While this would have enabled automatic publishing, exposing the Github password was even more unacceptable. Github -> Settings -> Personal Access Tokens Generate a Github Access Token that only has access to the current project and only has read permission, and encrypt the Access Token with Travis CI. Sounds a bit tedious, but the Travis CLI already does this with a single command:

travis setup release
Copy the code

After filling in the configuration items as prompted, the Travis CLI automatically generates all configuration items in the.travis. Yml file:

deploy:
  provider: releases
  api_key:
    secure: XXX
  file: app/build/outputs/apk/app-release.apk
  skip_cleanup: true
  on:
    tags: true
    all_branches: true
Copy the code

Secure under API_key is the encrypted Access Token.

It may be encountered when running the Travis Setup release

Invalid scheme format: [email protected] for a full error report, run travis report

Travis CLI does not yet support key access to Github, so you can temporarily switch the project source to HTTP and then switch back when it is successfully run:

git remote set-url origin https://github.com/AlloVince/evandroid.git
git remote set-url origin [email protected]:AlloVince/evandroid.git
Copy the code

During the actual deployment, the point at which publishing to Github Release pits was found to be

git push
git push --tags
Copy the code

Usually two Travis CI tasks are generated at the same time, but the default screen on the Travis web page only sees the last one run, and untagged tasks are reported

Skipping a deployment with the releases provider because this is not a tagged commit

It made me wonder if I had written my script wrong, but I couldn’t figure out why…

Automatically publish APK to FIR.im

Automatic updates to making for developers have enough, but considering the project actual needs and national conditions, or it is necessary to choose a domestic App distribution service, fir, im, dandelion is right choice, not only allows visitors to download, also provides a qr code is more suitable for docking phone functions, such as domestic download speed is fast. Because fir. Im provides a convenient CLI tool, this article uses fir. Im as an example and adds the following lines to.travis.

before_install:
- gem install fir-cli
after_deploy:
- fir p app/build/outputs/apk/app-release.apk -T $FIR_TOKEN -c "`git cat-file tag $TRAVIS_TAG`"
Copy the code

That is, install FIR – CLI in environment construction stage, and upload APK to FIR through FIR command line tool after successful release.

The $FIR_TOKEN can be found in the fir. Im user ->API Token, then create the environment variable FIR_TOKEN in the Travis CI console and paste it.

Here’s a trick: if we just upload the APK file to fir. Im, the testers who see the link don’t actually know about the changes contained in the release, so they upload the additional information contained in the current release tag with git cat-file tag $TRAVIS_TAG. The $TRAVIS_TAG variable is an environment variable that comes automatically with every Travis CI run, and there are many other Travis environment variables for us to play with.

An email notification is automatically sent after the release

Although Travis CI also has notification capabilities, you can’t customize templates, and the notification content is only a reminder of the results of a CI run, which is obviously more suitable for developers. We still hope that eventually we can notify team members in a more friendly way and give priority to domestic mail delivery services such as Submail and SendCloud considering the delivery rate.

Here we use Submail as an example. First we need to create a mail template in Submail. For example, we can create a triggered mail template like this:

A new version of @var(TRAVIS_TAG) has been released, with updated functionality: @var(Travis_description) download: http://fir.im/w13sCopy the code

Curl Curl Curl Curl Curl Curl Curl Curl Curl Curl Curl Curl

After_deploy: -curl -d "appId =10948&[email protected]&subject=[automatic notification] $TRAVIS_TAG &project= u2C0r2 & Signature =$SUBMAIL_SIGN&vars={\"TRAVIS_REPO_SLUG\":\"$TRAVIS_REPO_SLUG\",\"TRAVIS_TAG\ ":\"$TRAVIS_TAG\",\"TAG_DESCRIPTION\":\"$(git cat-file tag $TRAVIS_TAG | awk 1 ORS='

')\"}" https://api.submail.cn/mail/xsend.json
Copy the code

The authentication credential Signature used by Submail is also configured through the Travis CI console.

conclusion

The final completed sample project is here. In fact, all yML files can be configured in less than 30 lines, so you can save the tedious daily work. A final review of automated routines:

Submission code:

Git add. Git commit -mCopy the code

Play Tag

Git tag -a v0.0.1-alpha.1 -m "git tag -a v0.0.1-alpha.1 -mCopy the code

If you find an incorrect tag, you can delete the local and remote tags

Git tag -d v0.0.1-alpha.1 git push origin --delete tag v0.0.1-alphaCopy the code

Most Tag tags are only for internal testing, but it is still recommended to allow version semantics.

References

  • Travis CI User Documentation
  • Deploy Github Releases for Android projects using Travis CI

Tags : Android Travis

Follow :

Donate: Buy me a coffee | article helpful, can I have a cup of coffee, please