Android - Continuous Integration. Part 1

    I will not describe for the hundredth time what CI is and why it is needed. The inventor of this concept is, not unknown, Martin Fowler, but his work can be found here .

    I want to tell in a series of several articles about how to organize the development of Android applications using continuous integration. It was a surprise to me that, despite the popularity of CI, there is still no detailed instruction on the Internet, step by step, for beginners, even in English, not to mention Russian (well, or I simply didn’t find such ones).

    In the first article of the cycle, we will review the current dull situation and outline a plan of action for salvation - what we expect to receive at the end and for what we are up to. And then, gradually, we will begin to realize this. Who interested, I ask under the cat.

    I will consider all the examples on the following set of tools / technologies, although this is not fundamental and, for example, GIT can be easily replaced with Mercurial, and TeamCity with Jenkins:

    VCS - GIT
    Testing - Emulators, Android Instrumentation Framework, JUnit, Robotium, Robolectric, Mockito
    Building - Maven + android-maven-plugin
    IDE - IntelliJ IDEA
    Artifact storage - Nexus
    CI server - TeamCity

    What is available:


    So, the source codes of the project are in the GIT repository, the necessary libraries are stored there, all project participants commit to one main master branch, and assemblies for release are collected from there. There is no concept of tests, assembly is carried out by means of IntelliJ IDEA: Tools -> Android -> Export Signed Application Package.Collected artifacts between process participants are distributed by mail, skype and others. Preparation of the next release version can take up to several hours: switching the config file, changing the version number in the application, committing the release to the repository, creating a tag with the version number for committing, then checking that everything is assembled as it should, the application looks at the desired server and is signed with the necessary key and stuff. And despite all the checks and precautions, one should not forget about the human factor.

    What we want to get:


    The source codes are still in GIT :) The branching model in the repository is organized in accordance with this work and this remark , which helps to take into account the testing and correction phase of errors found. (In the future, this will make it easier for us to configure TeamCity, and indeed it will greatly facilitate the development, preparation for the release and its further support). Dependencies are automatically pulled from Nexus during assembly. Assembly is possible in two ways:
    • through the IDE, with the ability to connect debug and create various run-configurations using IDEA (convenient for local development, to quickly launch individual tests, etc.)
    • maven, in one click or fully automatically

    The project consists of three modules:
    • Root - the project root contains two other nested modules
    • App - module with the application. In addition to the application itself, it contains JUnit and Robolectric unit tests (in short - Robolectric , a library that allows you to run Android code in the desktop JVM, which significantly speeds up testing, unlike the version with Instrumentation tests).
    • Test - module with integration tests. Tests are written either using standard tools of the platform for testing ( Instrumentation Framework ), or using Robotium .

    Build-maven script collects application in three configurations development, testand production, by appropriate settings razlichiyuschihsya (server addresses, delays and timeouts, debug-flag, etc.). During assembly, unit and integration tests are run.

    The CI server performs the following assemblies:
    • Development - for each push in the develop branch. The purpose of the assembly is to detect errors as quickly as possible, such as "I forgot to commit the file, the project is not going to be collected from other team members."
    • Nightly build - build all three configurations from scratch and run the tests
    • UAT - assembly collecting release candidates during testing and fixing bugs found
    • Release - release testing assembly for putting on the market

    For each successful UAT or Release assembly, a view tag rcX.X.X-Xor a vX.X.Xcorresponding tag is created in the repository . If the build is overwhelmed: it does not compile, some of the tests are broken, etc. - A letter is sent with an alert to interested parties.

    Ready-made artifacts for testing or deployment to production are taken by project participants only from the CI server, no manual transfer. No need to think about a file with project configs or creating tags in the repository, everything happens “by itself”. The time to prepare and assemble a new release candidate for testing or release version is 2-5 minutes.

    In the next article, we will write our pom.xml for the maven and slowly begin to implement the plan of

    P.S. While preparing an article on Habré, a publication appeared on this topic, however, I will continue to write and share my experience

    Also popular now: