Continuous Integration for mobile and web projects

Good afternoon, in my article, I want to tell everyone the well-known practice of software development - Continuous Integration or Continuous Integration.
To immediately explain what the feature of the article is, I’ll explain that our team had the task of building a single process for all of our projects. And projects we have are both mobile (iOS, Android) and the web (typesetting, services, sites).

Introduction

At the very beginning, let me briefly tell you what continuous integration is and how it can come in handy.
Continuous Integration (Eng. Continuous Integration) - the practice of software development, which provides automated assembly of products to identify integration problems. Wikipedia

And if it’s simpler, it’s “just” the opportunity to receive a ready-made assembly of your product (application, site) when you click one button (or generally automatically).
How can this be useful?
First of all, your QA department will thank you, because they will not have to fiddle with the developer every hour in the hope of receiving an assembly for testing.
Secondly, you will have the opportunity to test your entire system as a whole, which will allow you to catch all the integration errors in advance.
And thirdly, the customer will be grateful if once he received a link to the project, at any time he will be able to see in what condition your project is and what it pays for.

So, the goal is to create a system for assembling projects for various platforms (web + mobile). The search led us to several existing solutions in this area:

  • Hudson
  • Cruisecontrol
  • Teamcity
  • Fastbuilder

Having looked at each, looking for the pros and cons, we settled on the Hudson option. This tool at that time seemed to us the most flexible and supported community. After we already learned that there is a Jenkins branch from it, but we did not start switching to it because Hudson was fine with everyone.
As a version control system, we historically chose Git, with the help of it we store versions of source codes and assemblies. Also, with the help of hooks we publish current versions of projects on a test server.
And finally, what we all started for is a corporate web portal that is responsible for user access to assemblies, storage of information on them, and finally for the ability to log in, download and test them. We called it Publisher and this is a simple web service written by us in Python (Django). It looks like this -
Continuous Integration portal

Implementation

And now more about how it all works:
When the project starts, a repository is created for the source code and a new project in Hudson. In the project settings, we specify the repository address and set the settings so that the repository is polled every 5 minutes and in case of changes, the assembly starts. There are many plugins for Hudson that can automatically assemble various types of projects, but we wanted to try everything ourselves and as a result, our assembly is a command-line script.
Assembly scripts themselves are different from project types.
The simplest is a web project, in which case the current version of the repository is archived and laid out for access.
Next in complexity is the assembly of the Android project, here at first we update the ant script (which are supported by the Android SDK by default) with the command, and then run the generated build script. For example, like this:

android update project --target 10 --name ProjectName
ant debug

As a result, we get a ready apk file that can be downloaded and installed on the device. In this example, we did not consider the option of signing a project for publication on GooglePlay. But, this can still be done using command line tools using the SDK utilities.
And finally, the most interesting option is the build of iOS. If you use the standard method offered by Apple, you need to assemble the application, sign it with the developer’s certificate, and only then install it (this is usually done through iTunes). We decided to simplify this process as much as possible. As a result, the project is assembled as follows: using the xcodebuild utility, we compile and assemble the project into the app application. After that, using the xcrun utility, we sign it with a developer certificate (which lies on the assembly server) and send the finished apk file to the public.

xcodebuild -project ProjectName.xcodeproj
xcrun -sdk iphoneos PackageApplication -v ProjectName.app -o ~/path/projectname.ipa -embed "~/path/provision.mobileprovision"

In this case, the Target that was installed by the developer in xCode itself is collected, but this parameter can also be set forcibly.
Finally, all the assemblies (ipa, apk, zip) are in the public domain and we are faced with the task of how to user check them. There is no problem with the web project - next to it there is a link to the test server, the Android apk file can simply be downloaded from the phone and installed. And there remains the problem of installing iOs applications. The user ideally, you just need to go to the portal from the device, click on the link and install the application. And there is such an opportunity. After reading the documentation and searching the Internet, we solved this problem. For the iPhone to follow the link to start installing the application, this link should be of the form itms-services: //? Action = download-manifest & url = http: //server/projectname.plist This address should contain the xml file the structure of which is described in the documentation and which can be obtained when building the project in xCode if you set the Enterprise checkbox when packaging the application. The main fields in this file are:

urlhttp://server/distribs/prokectname.ipabundle-identifierru.handh.projectnametitleProjectName

This file is generated automatically with us, when the assembly is published and now following the Install link in our portal from the iOS device, we will see a question about installing the application and, if agreed, we will see how the application downloads and installs.

Conclusion

At the moment, everyone involved in the project can visit our portal, download the latest version of the project and test it. And there we can publish projects of all the platforms that we deal with (Web, iOS, Android). And in the future we want to fasten there the publication of the results of Unit testing and notification of failed builds.

Also popular now: