Using Apphance Flow‎ > ‎Build steps‎ > ‎

Deploy your apps

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.

Standalone, simple release

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 <no-reply@youraddress.com>
release.mail.to = NO_TEAM@youraddress.com
release.mail.flags = qrCode,imageMontage,installableSimulators  

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.

Apphance-service supported release

This part of the documentation is upcoming.

Preparing application for release

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. 

iOS versioning

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):
  • CFBundleShortVersionString  - storing string name of particular version
  • CFBundleVersion - storing numeric bundle version (increasing with each release)
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. 

Android versioning

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. 
Comments