Continuous Integration for mobile and web projects
By: Heads
Tags: Application Development, Continuous Integration, iOS, Mobile App Development, Web Development

Greetings!

Today I want to share some knowledge about one commonly-known practice in IT development — Continuous Integration.

To make my text stand out from the regular wikipedia article I want to mention that our team had a task to create a unified process for all our projects. We have various mobile (iOS, Android) and web (services, sites, portals) projects.

Introduction

In the beginning let’s look at the term itself and see how it can be helpful.

According to Wikipedia continuous integration is a practise in IT development that automates the products’ adjustments for finding out the integration problems.

Speaking simply, — it’s just a way to have a ready build for your product (site, app) after one simple click on the button (or even automated completely).

How can it be useful?

First of all, your QA department will say you many thanks, because they won’t need to ask a developer every hour to have a test build for their needs. Secondly, you’ll have option to test your entire system. It will help you to find out all the integration mistakes in advance.

Thirdly, your client will be also grateful to receive one single link to a project that will be accessible all the time to see the stage of the development and find out where his money were invested.

So, the goal is to create a system for project builds for various platforms (web + mobile). Searching for an answer led us to a several solutions in this field:

Hudson

CruiseControl

TeamCity

FastBuilder

After looking carefully on every one of it and exploring all pros and cons we decided to go with Hudson solution. This instrument was the most flexible and the most supported by the developers around the world. Later we found out that there is a branch of it called Jenkins, but never transferred a project there ’cause Hudson was fine with us.

As a system to control the builds’ versions historically we had Git, with it help we store all the original codes and builds. Moreover, with the help of hooks we publish current versions of projects of test server.

Finally, the thing that we decided to create in the first place — unified corporate web-portal that corresponds to access of users to the builds, was created to storage the information about it and to log in, download and test all the builds and adjustments. We named it Publisher. It is a simple web-service that was written on Python (Django).

It looks like this:

Realization

Now it’s time to see how it all works together.

Right after the start of the new project the initial code and new project in Hudson is also being created. In the project settings we write the repository address and set it to be questioned every 5 minutes. In case of repository being modified, the new build creation starts automatically. There are many Hudson plugins that can automatically adjust various types of projects, but we wanted to create our own. In the end the process of adjustment we have is a one line command script.

The script itself varies based on the type of the project.

The simple one is the web project. In such case current version of repository is adjusted in one archive and published for people to access it. Android project is a little bit complex to adjust. In the beginning you need to update an ant scenario (in the default mode it’s supported by Android SDK) command, than we need to run the generated script of the build. For example, like here:

android update project — target 10 — name ProjectName

ant debug

In the result we’ll have ready apk file that you can download and install on your device. In this example we didn’t look at the scenario of project mentioning to publish it in GooglePlay. Still, it all can be made with a help of command line tools with SDK utilities.

Finally, the most interesting part is iOS adjustment. To use standard algorithm from Apple you need to adjust the app, than sign it with developer certificate and only after that you can install it (regularly it’s done through iTunes). We decided to simplify this process as much as we can. In the end we found such thing: with a help of xcodebuild utility we compile and adjust the project in app. Later with a help of xcrun utility we sign it with developer certificate (it’s accessible form builds’ server) and send the ready apk file to become accessible.

xcodebuild -project ProjectName.xcodeproj

xcrun -sdk iphoneos PackageApplication -v ProjectName.app -o ~/path/projectname.ipa -embed “~/path/provision.mobileprovision”

In such case we create that exact Target, that was installed in xCode of developer, but this parameter can be also changed manually.

In the end all adjustments (ipa, apk, zip) go to common access where it will be ready for users to check. There are no problems with web projects — they all have links to the test servers, Android apk file is can be downloaded with your phone where you can install it. The main difficulty is once again with iOS app. Ideally, user needs to go to the portal from his device, click on the link and install the app. And there is such possibility. After reading a pile of documentation and searching the internet we solved the problem. For iPhone user to be able to download an app by clicking the link it suppose to look like this:

itms-services://?action=download-manifest&url=http://server/projectname.plist

By this address you can access xml file, which structure needs to be described in documentation for adjustment project in xCode by clicking the ‘check’ on Enterprise window when adjusting the app. The main fields can be found in this file:

<! — link to the ipa file →

<key>url</key>

<string>http://server/distribs/prokectname.ipa</string> <! — app identificator →

<key>bundle-identifier</key>

<string>ru.handh.projectname</string> <! — name of the app →

<key>title</key>

<string>ProjectName</string>

This file is generated automatically in our case. That is why after adjusting a new build and clicking the Install link we see the question for permission to install an app. Upon agreeing we can see as an app being downloaded and installed.

Conclusion

Right now every project user can access the portal, download the latest version of the project and test it. Right now we can publish there all different projects for various platforms (Web, iOS, Android). Later on we want to add there an ability to publish the results of Unit testing and various notifications about failed adjustments.