Rebuilding a legacy app from the scratch (II): Adding Continuous Integration with Travis CI

Continuous Integration (CI) is a Software engineering practice where developers in a team continuously integrate their work in the main stream of source code at least once a day.

Why?

The main goal of the CI practice is to reduce the integration problems that quite often happen when we have a team of several people working in different features and parts of our system. The sooner we integrate our code the easier is to identify problems like dependencies between modules, compilation issues, regression, duplication in code, etc, etc.

How?

Continuous Integration is overall an attitude and good Software practice. In order to achieve it we need some tools and organisation.

First of all we need our source code in a repository, in our case to maintain MadridBus app we are using Github in a public repository.

Next we need a platform to perform the automatic builds of our code every time we push code to the repository. For our app we are going to use Travis CI. Travis is a hosted distributed CI platform, it’s free for public repositories and it’s quite easy to integrate and configure in our project.

Finally we need a good suite of Unit Test that are going to run every time a new build is launched, that as we mentioned before is going to happen for each push that we make in our repo. We will talk about the testing strategy in further posts but in the mean time you can take a look to one of my previous posts.

TRAVIS CI configuration

So first thing is going to https://travis-ci.org/ and we sign in with the Github account

where we have allocated the Android project.

Then we are going to select the project we want to set up with continuous integration and that’s pretty much it, we can start building!

But not so fast, probably your build is going to fail as we need to set it up properly for Android projects, and the way to do this is adding the “.travis.yml” configuration file.

Below you can see the current MadridBus Travis configuration file:

language: android jdk: oraclejdk8 cache: false sudo: true env: global: - ANDROID_API_LEVEL=25 - ANDROID_BUILD_TOOLS_VERSION=25.0.0 - ANDROID_ABI=armeabi-v7a - ADB_INSTALL_TIMEOUT=20 # minutes (2 minutes by default - see #247) android: components: - platform-tools - tools - build-tools-$ANDROID_BUILD_TOOLS_VERSION - android-$ANDROID_API_LEVEL # Google Play Services - extra-google-google_play_services # Support library - extra-android-support # Latest artifacts in local repository - extra-google-m2repository - extra-android-m2repository # Specify at least one system image - sys-img-armeabi-v7a-android-$ANDROID_API_LEVEL # Emulator Management: Create, Start and Wait before_script: - echo no | android create avd --force -n test -t android-21 --abi armeabi-v7a - emulator -avd test -no-skin -no-audio -no-window & - android-wait-for-emulator - adb shell input keyevent 82 & script: - android list target - ./gradlew connectedAndroidTest licenses: - 'android-sdk-preview-license-.+' - 'android-sdk-license-.+' - 'google-gdk-license-.+'

Right, so let’s take a look to the interesting parts. As you can see in the first two lines we are specifying the project type with “language: android” and the JDK version 8 to be used to compile with “jdk: oraclejdk8”.

Right now by default Travis will build our project with Android SDK 24, so if we want to install and build with a latest SDK and use any other additional component we need to specify it as we can see it in the section “components” under the “android” tag.

As you can see in the example we are indicating that we want to use Build Tools version 25.0.0, Android SDK 25 and also that we are using Google Play Services adding “extra-google-google_play_services”. One important thing here is to tell Travis to accept all the licences when installing additional components, otherwise the build will fail. For this we are adding the section “licenses” as you can see above.

Finally we want to launch an emulator so we can run the tests. To accomplish this we are adding the section “before_script” where we are launching and waiting until is running for the emulator with the image type as configured in the field “sys-img-armeabi-v7a-android-$ANDROID_API_LEVEL”.

And that’s it! We just need to push new code to the repository and Travis will build automatically the project and run the tests for us.

In next posts we will see how to add our testing strategy including Unit Tests with JUnit, Integration Tests with Espresso, mocking with Mockito, etc.
Stay tunned!

Originally published at davidguerrerodiaz.wordpress.com on December 4, 2016.