System of automatic assembly of mobile applications Alawar Build System

Hello!

In this post we want to share the experience of creating an automated system for assembling mobile applications, in our case, games for the iOS platform.

We are faced with the need to automate the assembly and deployment to test devices, when the size of the fleet of devices has exceeded two dozen, and the number of projects simultaneously in QA has reached 30+. With such volumes, the deployment of the build to test devices using “Build & Run” in Xcode began to noticeably slow down the QA process. It was decided to automate the process of assembling and uploading builds to devices.
')
Our updated build system consists of three main components:

• Repositories with source codes of projects;
• Build server;
• Server distribution of builds on devices.

The process of passing a project version from developers to testers is as follows:

• The developer makes a commit version to the repository;
• The build server starts the build of the corresponding project;
• In the case of a successful build, the build is laid out on the distribution server;
• The final IPA is installed on the device “over the air”.

Let us dwell in more detail on each of the main components.

Repositories

We use Subversion as a source code repository, this hard currency is easy to use, the client is on a Mac from any iOS developer out of the box. There are only two subtle points with SVN:

• By default, the SVN client is configured to ignore the * .a mask, this leads to the fact that static library files are not added to the repository. This setting must be overridden on all client machines.
• To start the project build in automatic mode, we have an onAfterCommit hook set up that checks in the comments to the commit the presence of the “READY” tag, with which the developer marks the version ready for build and transfer to QA.

Build server

We chose Jenkins , deployed on a Mac server, as the core of the build server. Jenkins is open, free, easy to install and configure, easily expanded by third-party plugins and is actively supported.
The actual build of the project consists in checking the source code and invoking the xcodebuild command with the appropriate parameters.
The main (assembly) part is a bash script that looks like this:

#   xcodebuild -target "${TARGET}" -configuration "{$CONFIGURATION}" -project "${XCODEPROJ}" CODE_SIGN_IDENTITY="${CERTIFICATE}" PROVISIONING_PROFILE="${PROVISIONING_ID}" CONFIGURATION_BUILD_DIR="${CONFIGURATION_BUILD_DIR}" #   $XCODEPROJ, $TARGET  $CONFIGURATION      #  $CONFIGURATION_BUILD_DIR  ,      app #   $CERTIFICATE  $PROVISIONING_ID     ()     #   IPA xcrun -sdk iphoneos PackageApplication -v "${APPLICATION_NAME}.app" -o "${WORKSPACE}/orig_${APP_NAME}.ipa" #     curl -f -k --form "data[email]=${AIRONAPP_USER}" --form "data[password]=${AIRONAPP_PASSWORD}" --form "data[application]=${AIRONAPP_ID}" --form "data[ipa_file]=@${IPA_FILE}" ${AIRONAPP_URL}/api/1.0/http/uploadIPA 

Given that our developers are working on different versions of XCode, we support the build with four different versions (as of the moment of writing the post): 4.2.1, 4.3.1, 4.5.1 and 4.5.2. By default, the latter is used, with the ability to specify a specific version for a specific project. This feature turned out to be particularly relevant at the moment when the Unity3D game engine had a known compatibility bug with iOS SDK 6.0 and XCode 4.5.x. (Fix was released in Unity3D version 3.5.6) After the build, the received app is packaged in ipa using the PackageApplication utility, and the resulting ipa file is sent to the distribution server of the builds. If the assembly “collapses” for some reason, the developer receives by mail the full console log with all error messages. Both Alawar release managers (to be able to start building a project manually) and external developers have access to Jenkins, for example, in order to get dSYM files for analyzing crash logs.

We use Mac Mini Server (Core i7 4 * 2.7GHz, 16Gb RAM, 1Tb HDD) as a hardware, this configuration confidently copes with the simultaneous assembly of four game projects. The average assembly time does not exceed 15 minutes (for projects of the “hidden object” genre, where the size of the final ipa file is 400-600Mb). Jenkins is configured to work in 1 master with 4 assemblers. Of the installed plugins can be noted:

• Subversion Release Manager - allows you to explicitly specify the revision for manual assembly;
• Log Parser - parses the console output of XCode according to predefined templates and makes easy navigation through errors;
• Clang Scan-Build - runs a static analyzer and generates reports of potential leaks;
• Priority Sorter - allows you to set projects priorities and collect more urgent / important in the first place.

Server distribution builds "by air"

As a service for the distribution of ipa-files, we use a ready-made solution from Arello Mobile - the AirOnApp service. In fact, this is an analogue TestFlight with additional "buns", such as:

• The service is deployed on our server platform in the office, which saves us from external traffic;
• The ability to conveniently add new devices to the team account from the admin panel AirOnApp;
• The ability to publish applications in the App Store from the same admin panel.

In addition to the build distribution server, we use a small client application to which a push notification containing a link to install the build is sent to a successful build.

To date, we have received:

• Stable automated build and deployment of builds. It allows you to conveniently and quickly accept the version from the developers, make sure that the source codes are correct and spread the build to test devices with minimal human participation.
• A clear scheme of versioning projects. With this scheme, any participant in the process always knows which version of the application is installed on the device, in which version a bug is found, etc.
• A handy toolkit for working with an Apple account. It allows you to add a new device to your account, add it also to provisional profiles, re-sign builds with updated provisioning, submit applications to the store.

In the future, we plan to implement support for the automatic assembly of applications for all major platforms with which we work (MacOS, Android, Windows, Windows 8, etc.), creating a cluster of collectors on several physical machines running corresponding OS with a single Jenkins admin panel .

I would be happy to answer your questions in the comments or hear stories about how such problems are solved in your company.