OTA deployment is a way to install application remotely from a binary placed in publicly available location. This is very convenient way of distributing the application. It requires special processing of binary files (in case of iOS it requires to create .ipa file), html pages and manifest files need to be generated, multiple variants should be embedded in single web page displayed. E-mail communicating that new software is prepared and it is ready to be sent to involved people (usually development and test team).
OTA deployment is not very well documented for iOS, we developed custom solution that prepare everything that is needed to have application OTA-deployed in single task. It's far easier for Android, but we provide the very same mechanism to generate OTA-deployment.
Since such deployment requires server side support, Apphance Flow provides two ways of OTA deployment preparation. One for projects which are not using Apphance service, and another for projects using it.
In this case the only thing that Flow can do is to generate static .html pages which someone has to make available on your organisation-controlled web site. How such generated files should be transmitted to the web server is beyong the scope of Flow - it can usually be automated by writing your own, custom gradle task, or Jenkins "artifact copy" plugin.
The files that provide custom OTA deployment are generated in "ota" directory of the project under flow-ota subdirectory of proejct root. Note that in case of iOS, some of the URLs in generated manifest must be absolute URLs, therefore at build time you need to provide release.url property which says where the generated files will be placed eventually.
The files that Apphance Flow will generate will be placed in "flow-ota/SomeProject" directory. This (whole) directory should be copied to the web server and made available at http://youraddress.com/ext/SomeProject/ URL.
Apphance Flow - in the same directory - generates set of .html and binary files as well as HTML mail message that can be then sent later to appropriate people, according to release properties. The generated mail contains URL link that can be opened in the mobile :
release.mail.from = Jenkins <firstname.lastname@example.org>
You can specify if this mail should contain qrCode for the installation link (useful to scan it from the device without typing the link), also imageMontate (as explained in Software delivery) can be attached to the mail/linked from it so that it is very easy to distribute the application-related code to testers.
This part of the documentation is upcoming.
Preparing application for release involves setting application's version name and increasing application's version code. While string text name of application version is something that is visible to the user, version code is always numeric and should be always incremented, so that it can be later upgraded via mechanisms of appropriat application market.
In order to get versioning correct, XCode project should have the two plist configuration strings defined (they are defined in main .plist file of the application):
These two values are updated before build when updateVersion task is executed. Values to both parameters are passed as properties when executing updateVersion task. These are version.code, version.string and release.notes parameters that control it. You can find examples how to make your Jenkins iOS job setup (in our example Jenkins) in order to get to get the manual version entered by the user and version code taken automatically from Jenkins build number.
Similarly as in iOS, Android has two version numbers: numerical version code and manually entered version string. You can find examples how to make your Jenkins Android job setup (in our example Jenkins) in order to get to get the manual version entered by the user and version code taken automatically from Jenkins build number.