Recently paid to buy Travis Ci,travis CI is interesting, not by project or user, but by the work process, such as the initial version is $129/month, a total of 2 work processes. In the case of a few projects, in addition to running unit testing, it is unavoidable to use more fully, so the time to build a set of Travis CI-based Android Automatic publishing workflow.
Pre-automated Android development always avoids this workflow:
- Develop some new features, submit code
- After completing some of the features, pack a beta apk
- Upload Beta apk to QQ Group/network disc/fir.im/dandelion etc.
- Explain the functions of the current version in QQ Group or publishing platform
- Notify testers to test
With this set of automated releases, the workflow is streamlined to:
- Develop new features, submit code
- By
git tag
playing a beta version of the code tag, in the description of the tag to write the current completion of the function
After the tag is submitted, Travis CI will automatically compile the code, generate the APK file and distribute it to GitHub and Fir.im,github and fir.im will keep the tag description information, after the distribution is completed, there will be an email notifying all the people involved in the test. And as a developer, you just need to focus on the code to hit good one tag.
The whole process seems to have done a lot of work, in fact, reflected in Travis CI only a few lines of instruction, the following one after the explanation:
Enable Travis CI for Android projects
Travis CI should be one of the best continuous Integration services available now, if the code base is based on GitHub, it can be very simple to open. Since this article covers many of the basic concepts of Travis CI, it is recommended that you understand the custom build section of Travis Ci first.
I also wrote about how to use Travis CI in a PHP project earlier in the introduction of continuous integration of PHP projects. The steps are almost identical for Android projects:
First prepare a .travis.yml
file to be placed in the root directory of the Android project, which .travis.yml
records the basic information required for Travis CI:
falseandroid: components: - build-tools-23.0.1 - android-23 - extra-android-m2repository - extra-android-supportscript: - "./gradlew assembleRelease"
No need to read the document can be through the above configuration probably know, we want to run an Android project, the Android SDK version is 23, the project uses the Buildtools version of 23.0.1, to compile this project we also introduced some necessary components, such as support Library (Extra-android-support), Android support Repository (extra-android-m2repository), etc.
When Travis Ci is ready for the environment that we need, the instructions set in the Yml file section are automatically run, and the script
previous example runs ./gradlew assembleRelease
, and the successful operation is generated under the main module of the project build/outputs/apk/app-release.apk
.
Finally, enter the Travis CI homepage and log in directly using the GitHub account with Project admin privileges. Select the project to turn on Travis Ci, and set the switch on the right to on.
Travis CI currently has 2 sites: if it is open source projects, directly into the travis-ci.org can, if it is a private paid items, you need to enter the travis-ci.com,2 site except for the domain name all the interface and operation almost identical.
There is also a line in the configuration that sudo: false
is designed to enable container-based Travis CI tasks, making compilation more efficient.
Password and certificate security built by Android automation
Android Project publishing requires a certificate file and several passwords, but no matter whether it is an open source project or a private project, the original certificate or password should not be placed in the code base at any time (in principle, the certificate and password should not be delivered to the developer, but should only be compiled from the publisher). Travis CI provides 2 solutions for this, such as sensitive information, passwords, certificates, etc. symmetric encryption, in the CI build environment decryption, the other is the password through the Travis CI console (that is, the Web site) set to the environment variables at the time of construction.
Since the former generates a pair of environment variables in the Travis console, I would try to choose the latter, but since the Travis console is unable to upload the file and therefore involves the part of the file encryption, you can only select the former one.
Having said that, the first thing you need to do is to retrofit your compilation scripts, and if you don't consider security issues, your project's build.gradle
files might look like this:
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 } }}
And we ultimately want to effect, or hope that a compilation script can be used both in the development environment, but also in the CI environment, in Travis CI, you can click on the project name, Settings, environment variables set environment variables, For example, we can set the above configuration, respectively, KEYSTORE_PASS
ALIAS_NAME
ALIAS_PASS
Three environment variables, in the Travis CI environment can be System.getenv()
obtained by these environment variables.
In the local development environment, my approach is to add these variables to the gradle.properties
file so that they can be build.gradle
used directly inside. The following is the development environmentgradle.properties
KEYSTORE_PASS=123456ALIAS_NAME=evandroid_aliasALIAS_PASS=654321
build.gradle
so it becomes a
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") }
Next processing the certificate file, in order to facilitate file encryption and other functions, Travis CI provides a ruby-based CLI command-line tool, you can directly use the GEM installation
gem install travis
After installation, go to the Android project root directory and try to encrypt the certificate file:
--add
If you run for the first time, Travis will be prompted to log in, run travis login --org
and enter the GitHub username and password. (The paid version is travis login --pro
)
travis encrypt-file
Instructions will do a few things:
- The Travis CI console automatically generates a pair of keys, such as:
encrypted_e41864bb9dab_key
,encrypted_e41864bb9dab_iv
- The file is encrypted based on the key
openssl
, and the project root file is generated in the previous example evandroid.jks.enc
- In the
.travis.yml
automatic generation of Travis CI environment in the decryption file configuration, the above example can be seen after running a .travis.yml
few more lines:
before_install:- openssl aes-256-cbc -K $encrypted_e41864bb9dab_key -iv $encrypted_e41864bb9dab_i -in keys/evandroid.jks.enc -out keys/evandroid.jks -d
Travis CI runs by default in the project root, so be careful to adjust the path of the enc file based on the actual requirements.
Finally, don't forget to .gitignore
ignore them in and keys/evandroid.jks
gradle.properties
delete them in the code base.
Travis CI automatically releases Android apk file to GitHub release
After the partial run of Travis CI is script
successful, the configuration file can be entered into the release phase. The following is an example of a Travis CI release:
deploy: provider: releases "GITHUB USERNAME" password: "GITHUB PASSWORD" file: app/build/outputs/apk/app-release.apk skip_cleanup: true on: tags: true
This example configures some of the following:
provider
: Released to GitHub release, Travis CI supports dozens of provider, including AWS, Google APP engine, and beyond GitHub
- GitHub username and password because Travis CI is uploading the apk file, so you need to have write access to the GitHub project
file
: Publish file, enter file path
skip_cleanup
: By default, Travis CI clears all generated files after compiling, so it needs to be skip_cleanup
set to true to ignore this operation.
on
: The timing of the release, which is configured here tags: true
, is published only when there is a tag
situation.
While this can be done automatically, it is even more unacceptable for us to expose the GitHub password directly. A better practice is to generate a github access Token that can only access the current project and read permissions on Personal access tokens, settings, GitHub, and through Travis CI will access Tok En encryption. It sounds a little cumbersome, but fortunately the Travis CLI can do it all by a single line of instructions:
travis setup release
When prompted to fill in the information for the above configuration item, the Travis CLI automatically .travis.yml
generates all the configuration items in the file:
deploy: provider: releases api_key: secure: XXX file: app/build/outputs/apk/app-release.apk true on: tags: true all_branches: true
The api_key
next one secure
is the encrypted access Token.
At run travis setup release
time it is possible to encounter
Invalid scheme format: [email protected] For a full error report, run Travis report
This error appears to be the Travis CLI also does not support access to GitHub via a key, so you can temporarily switch the source of the project to HTTP, and then switch back when it runs successfully:
set-url origin https://github.com/AlloVince/evandroid.gitgit remote set-url origin [email protected]:AlloVince/evandroid.git
In the actual deployment process, it was found that the points published to the GitHub release compare pits are
--tags
Will often generate 2 Travis CI tasks at the same time, but in the Travis Web page, the default interface can only see a final run of a task, and the task of not playing tag will be reported
Skipping a deployment with the releases provider because a tagged commit
It once made me think that my script was wrong, but I couldn't find the wrong reason ...
Auto release apk to fir.im
Automatically released to GitHub for developers is enough, but considering the actual needs of the project and national conditions, or it is necessary to choose a domestic app distribution service, fir.im, Dandelion is a good choice, not only to allow visitors to download, but also provides a QR code and so more suitable for docking cell phone functions, Domestic download speed is also very fast. Because fir.im provides a more convenient CLI tool, this article takes fir.im as an example, .travis.yml
adding the following lines in:
$FIR_TOKEN -c "`git cat-file tag $TRAVIS_TAG`"
That is, install FIR-CLI during the environment build phase and upload the apk to fir with the FIR command line tool after successful release.
This $FIR_TOKEN
can be found in the fir.im user->api token, and then the environment variable is created and pasted in the Travis CI console FIR_TOKEN
.
Here's a tip, if we just upload the apk file to fir.im, the testers who see the link don't actually know the changes that were included in the release, so they git cat-file tag $TRAVIS_TAG
uploaded it together with the additional information contained in the current release tag. The $TRAVIS_TAG
variables are the environment variables that Travis CI runs automatically with every run, and there are many other Travis environment variables for us to play more tricks on.
Automatic e-mail notification upon completion of publication
Although Travis CI also has notification function, but can not customize the template, the notification content is only to prompt the results of CI operation, obviously more suitable for developers. We still want to finally be able to inform the team members in a more friendly way, taking into account the mail delivery rate, we can give preference to domestic mail sending service such as Submail, Sendcloud and so on.
In Submail, for example, you first need to create a mail template within Submail, for example, we can create such a trigger mail template:
Hi 亲@var(TRAVIS_REPO_SLUG)新版本@var(TRAVIS_TAG)已经发布了,功能更新:@var(TAG_DESCRIPTION)去下载:http://fir.im/w13s
After creation, you can get the message template ID, according to the Submail manual, put the required variables into the template, and eventually you can use a line of curl instructions to send a message:
after_deploy:- curl -d "appid=10948&[email protected]&subject=[自动通知] 安卓新版本$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=‘<br>‘)\"}" https://api.submail.cn/mail/xsend.json
The authentication credential signature used by Submail is also configured by the Travis CI console.
Summarize
The final completed sample project is here. In fact, all the Yml file configuration less than 30 lines, you can save the tedious routine work, why not. Finally, review the automated routine:
Submit Code:
commit -m "这里是注释"git push origin
Play tag
--tags
If you find the wrong tag, you can delete the local and remote tag
git tag -d v0.0.1-alpha.1git push origin --delete tag v0.0.1-alpha.1
Ask Ah app, programmer answer artifact, solve all your technical problems, HTTP://T.CN/R4VE2D7 download register to send 5 yuan quickly to download register it!
QQ group 290551701 gathers a lot of Internet elite, technical director, architect, project Manager! Open source technology research, Welcome to the industry, Daniel and beginners are interested in engaging in IT industry personnel to enter!
Build Android Automated packaging publishing workflow based on Travis CI (supports GitHub release and fir.im)