This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
build:jenkins [2018/10/18 23:24] mjallison [Server Builds] |
build:jenkins [2018/10/25 17:50] (current) mjallison [Web Application Builds] |
||
---|---|---|---|
Line 17: | Line 17: | ||
Jenkins will kick off a build (usually within 15 minutes, configuration time) when new code is | Jenkins will kick off a build (usually within 15 minutes, configuration time) when new code is | ||
- | checked into the associated repository. | + | checked into the associated repository. |
+ | |||
+ | |||
+ | Everything discussed here runs under the build account (u=build/pw=build396). | ||
====== Android Builds ====== | ====== Android Builds ====== | ||
Line 30: | Line 33: | ||
(manually) to /var/www/html/build/SmartDirt (btw: historical reasons for the name, nothing fancy). | (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. | 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" >\\ | ||
+ | |||
+ | '' | ||
====== Server Builds ====== | ====== Server Builds ====== | ||
Line 40: | Line 57: | ||
This is done with the following commands: | This is done with the following commands: | ||
- | ''ssh -P 23456 build@dev.agtek.com | + | ''ssh -P 23456 build@dev.agtek.com\\ |
- | # after completing the log-in | + | # after completing the log-in\\ |
- | snap | + | snap\\ |
- | '' | + | ''\\ |
The "snap" script will copy the release items from the latest build, AND lay a versioned/dated tag on the branch. | 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 "snapped" server components will be in a directory called something like "server-2018-10-18". | ||
Line 55: | Line 73: | ||
When the build has completed the build user must capture a version of the application. This is done with the following commands: | 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 | + | ''ssh -P 23456 build@dev.agtek.com\\ |
- | # after completing the log-in | + | # after completing the log-in\\ |
- | snap | + | wsnap\\ |
- | '' | + | ''\\ |
After a "wsnap" the server components are stored in a directory like "accessweb-2018-10-18". | After a "wsnap" the server components are stored in a directory like "accessweb-2018-10-18". | ||
- | Inside are two WAR files; | + | 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. | ||