The Jenkins build system is installed on dev.agtek.com. It's a Java application running within the Tomcat application environment. The build system for Agtek will perform continuous integration builds for Android components, as follows:

• AGTEKBaseSetup
• SimpleTrack
• SmartBlade
• SmartDirt
• SmartGrade
• SmartPlan
• SmartTrack

and Server components as follows:

• AgtekNet (the Access server itself)
• AccesWeb (the web application)

Jenkins will kick off a build (usually within 15 minutes, configuration time) when new code is checked into the associated repository.

Everything discussed here runs under the build account (u=build/pw=build396).

Each Android project will checkout two repositories; AGTEK_Lib and the associate application repository. A script, AGTEK_Lib/jenkins.sh, does the heavy lifting of running the build for each part of the application. For most part, jenkins.sh will set build numbers (from Jenkins itself), and runs the Android “assemble” task. The build fails if no APK is produced.

Once the build succeeds, the corresponding APK and mapping file are copied to /var/www/html/build/SmartSuite-nightly.

When the product has been tested and is accepted for distribution, the APK and mapping files are copied (manually) to /var/www/html/build/SmartDirt (btw: historical reasons for the name, nothing fancy). Old release copies should then be copied to /var/www/html/build/SmartDirt/old.

Building an Android app for release on the Play store takes a couple of more steps. Each play store version is identified by an integer (variously called a “build number” or “release number”). This integer is only loosely related to the versions string (e.g. 1.5.2) in that the build number must always be larger than the previously release.

These release numbers are constants defined inside the Manifest (example from TrackManager, release == 11):

<manifest xmlns:android=“http://schemas.android.com/apk/res/android“
package=“com.agtek.trackmanager”
android:versionCode=“11”
android:versionName=“1.4.1” >


The AccessServer is built via a regular ant script, and all the code is contained in a single repository. Typically the build system is building from the branch “master” and seldom builds from release branches.

Each build run also runs the JUnit unit tests. A failure of the unit tests will cause the build to fail.

When the build is ready for roll out, the build user must capture the built copy of the server. This is done with the following commands:

ssh -P 23456 build@dev.agtek.com
# after completing the log-in
snap


The “snap” script will copy the release items from the latest build, AND lay a versioned/dated tag on the branch. The “snapped” server components will be in a directory called something like “server-2018-10-18”.

The AccessWeb application is build via a regular ant script, and all the code is contained in a single repository. Typically the build system is building from the branch “master”, but maintenance branches have been set up and builds may occur from them. As of the current date (2018-10-18) the only build configured is for the “1.4” release line.

When the build has completed the build user must capture a version of the application. This is done with the following commands:

ssh -P 23456 build@dev.agtek.com
# after completing the log-in
wsnap


After a “wsnap” the server components are stored in a directory like “accessweb-2018-10-18”. Inside are two WAR files; AccessWeb.war and AccessWeb##support.war.

The “AccessWeb.war” file is the AccessWeb application to be deployed in the Tomcat server. The servers are either “apps.agtek.com” or “beta.agtek.com”. Which actual server the web app is deployed to depends on the state of the current release (testing vs. production roll out).

The “AccessWeb##support.war” file is the Support web tool for the support department. It is always installed in the Tomcat instance running on dev.agtek.com.