Android uses the Jenkins continuous integration environment to generate all of the builds. Jenkins is configured to watch the Git repositories for changes that trigger new builds in the system. Each product has multiple projects in Jenkins. The projects are grouped into two categories: Development and Release.

The projects are named using the name of the product to build. The Development projects are just the product name. (ex. SmartDirt, SmartPlan etc). The Release projects are the product name followed by a version number. (ex. SmartDirt-2.4.0).

In the Agtek_lib repository there is a script file called jenkins.sh. This is a Bash script that tells Jenkins how to build an Android app. The same script is used for all the Android apps. This script controls the build, testing and distribution of the results.

Prior to building the software we need to insert some information to be included in the upcoming build. This is the build type and build number which shows up on the About screen of the applications. The build type is Dev, Alpha, Beta and Release. The build number is an available environment variable supplied by Jenkins. The change is made by editing the strings.xml file and swapping the word “ROGUE” for the appropriate string. The following formats are used:

• Dev-1234 where 1234 is the build number
• Alpha-1234
• Beta-1234
• Release

As can be seen above there is a notion of build type. There are four available build types: dev, alpha, beta, rel. The “dev” type is a development build as described above. The alpha, beta and rel builds are release build types as described above.

The jenkins.sh script can be controlled using command line options. These options are as follows:

• jenkins.sh <build type: dev, alpha, beta, rel> <build directory> <Product Name> <Version>

For dev build types the Version is not used. It is required for the other build types.

Jenkins is told how to run this script from the project configure section. Under Build Triggers the Build section contains a line similar to the following:

• bash AGTEK_Lib/jenkins.sh alpha smartdirt SmartDirt 2.4.0
• exit $?

This particular code tells Jenkins to use Bash to run the AGTEK_Lib/jenkins.sh script. This build type is “alpha”. It will build “smartdirt” which is the relative directory name of where the code is located. The product name is “SmartDirt”. Notice the capitalization. This is what the APK will be named. The release is “2.4.0”. This is also used to name the APK (ex. SmartDirt-2.4.0.apk)

Assuming everything works the resulting APK will be located in /var/www/html/build/SmartApps-Android. Under this directory there will be one directory for each of the products (SmartDirt, SmartPlan etc.). In each of these directories there will be directories Dev, Alpha, Beta, Rel.

The Dev directory will contain 30 days of the continuous development builds which are identified by their build numbers. The Alpha, Beta directories are used for testing phases and contain the latest build only. The build number is identified on the About screen for the test images. The Alpha and Beta testing phases are run using the Play Store pre-release testing capabilities. The Rel directory contains the latest release candidate build. When we decide to push a release to the play store this is where that APK is retrieved.

When we decide to create a release for a product we need to create a new branch to hold that release. The branch is named release/<Product Name>-<Version>. The version needs to be agreed upon prior to creating the branch. All updates to this release branch are for stabilization of the release. All testing phases are driven from this release branch.

Once the release branch is created a new project needs to be created in Jenkins to service the release branch. The easiest way to do this is click on the “New Item” button from the main Jenkins screen. A project name is needed. This name should be the name of the release branch (ex. SmartDirt-2.4.0). The easiest way to create this new project is to copy an old project. Typically this would be the previous release of the project. In the “Copy From:” area start typing and information is filled in. In the case of SmartDirt-2.4.0 the previous version was SmartDirt-2.3.1. Click OK and you are good to go.

Now you can select the project you just created from the main Jenkins screen then you need to Configure the project. Click on the “Configure” button then on the next screen either scroll down or click on the “Build Triggers” tab. The following section will show:

If you copied from the last release you should see something similar to the above picture. Notice the build type is set to “rel” and the version is set to “2.3.1”. Since we just created a new release branch and project the first phase for that is Alpha testing. So edit the script arguments and change “rel” to “alpha” and the version from “2.3.1” to the version you created. Once these changes are made you need to scroll to the bottom and click “Save” for them to take effect.

Now Jenkins is configured to build your release. It is triggered by updates to the release branch and the resulting APK will be put in the “Product Name”/Alpha directory.

The Alpha, Beta and Rel type builds are the only build types that can be pushed to the Play Store. Alpha testing is internal testing within Agtek. Beta testing is external customer testing. We currently don't do Beta testing. Rel is the actual customer release. There should be no reason to create a Rel build until Alpha and/or Beta are signed off as complete.

The Google Play Store has the same notion for testing. It has an additional notion of a pre-alpha testing which may be useful, however there is really no difference for Agtek purposes, so going directly into Alpha seems to work fine.

When an APK is pushed to the play store it can't be overwritten or deleted. This means that the Manifest build number must be incremented for each APK pushed per product.

There is a list of testers identified by their gmail accounts. It must be gmail. Once the test release is created a URL is provided which must be copied and sent to each of the testers. They can click on this URL to opt into the test. The latest test release will automatically be installed on their device as long as a previous version was installed. If they don't have app installed they can use the link in the email to install it from the play store.

The Android build and integration environment starts with Git. The core of any development environment is the source control system. Currently the Android code is organized in several repositories on a BitKeeper Git server. There is a base repository that contains the shared Agtek_lib code. Each of the products are in their own repositories such as SmartDirt, SmartPlan etc. Android Studio projects are put together using a product repository along with the Agtek_lib repository.

There is a problem with this organization in that changes to Agtek_lib effect all the other products. This causes some extra work to mirror the branches in all the effected repositories. Any changes are managed separately and must be pushed together to create a single update to the entire system. There is a bunch of extra work involved as well as a lot of room for mistakes.

Currently Agtek uses different source control for each platform. The desktop is on Visual Source Safe. iPhone is using Github and Android is using Bitkeeper. A decision has been made to consolidate on Github. The primary reason for this is ease of access no matter where you are developing code.

The iPhone code is currently stored in a single Github repository called SmartApps. The proposal is to move all the Android code from Bitkeeper to Github. The process for doing this will be to migrate the separate repositories into a single SmartApps-Android repository. There is a process for pushing the repository into a directory under a new repository and maintaining all the history. It will require creation of some scriptware and all the code to updated and pushed. The process shouldn't take more than a few hours. Since Bitkeeper is also based on Git we can do this process on Bitkeeper and get things working again then push the result to Github.