Android - Continuous Integration. Part 1

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



I want in a series of several articles to talk about how to organize the development of Android applications using continuous integration. For me, it was a surprise 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 did not find such).



In the first article of the cycle, we will review the current sad situation and outline a plan of action for salvation - what we expect to receive at the end and for what we are doing everything. And then, gradually, we will begin to implement it. Who are interested, please under the cat.



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

')

VCS - GIT

Testing - Emulators, Android Instrumentation Framework, JUnit, Robotium, Robolectric, Mockito

Building - Maven + android-maven-plugin

IDE - IntelliJ IDEA

Artifact Store - Nexus

CI server - TeamCity

What is available:

So, the project source codes are in the GIT repository, the necessary libraries are stored there, all project participants commit into one master master branch, and assemblies for release are also collected from there. The concept of tests is missing, the assembly is carried out by means of IntelliJ IDEA: Tools -> Android -> Export Signed Application Package. Collected artifacts between participants in the process are distributed by mail, Skype and other. Preparing 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 on the commit, then checking that everything is assembled as needed, the application looks at the server you need and signed it key and stuff. And despite all the checks and precautions do not forget about the human factor.

What we want to get:

The source codes are still in GIT :) The branch branching model in the repository is organized in accordance with this work and this observation , which helps to take into account the phase of testing and correcting errors found. (In the future, this will allow us to set up TeamCity more easily, and in general will greatly facilitate development, preparation for release and further support for it). Dependencies are automatically pulled from Nexus during assembly. Assembly is possible in two options:

• via IDE, with the ability to connect debag and create various run configurations using IDEA (convenient for local development, for quick launch of 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 testing platform ( Instrumentation Framework ) or using Robotium .

The build script for maven allows you to build an application in three configurations: development , test and production , differing by their respective settings (server addresses, delays and timeouts, debug-flag, etc.). During the assembly run unit and integration tests.



The CI server performs the following assemblies:

• Development - for each push in the develop branch. The purpose of the assembly is to identify as quickly as possible errors like “I forgot to commit the file, the project is not being collected from other team members.”
• Nightly build - build all three configurations from scratch and run tests
• UAT - build that assembles release candidates during testing and fixing found bugs
• Release - release testing assembly for putting it in the market

For each successful UAT or Release assembly, a tag of the form rcX.XX-X or vX.XX is created in the repository, respectively. If the build is littered: not compiled, some of the tests are broken, etc. - A letter is sent with an alarm to interested persons.



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



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



PS While I was preparing an article on Habré a publication on this topic appeared, nevertheless, I will continue to write and share my experience