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.
In order to immediately explain what is special about the article, I will explain that our team had the task to build a single process for all our projects. And we have projects as mobile (iOS, Android) and web (layout, services, websites).
At the very beginning, let me briefly explain what continuous integration is and how it can be useful.
And if it is simpler, it is “only” the possibility, when you press one button (or automatically at all) to get a ready-made assembly of your product (application, site).
How can this be useful?
First of all, your QA department will thank you, as they will not have to tamper with the developer every hour in the hope of getting 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 integration errors in advance.
And thirdly, the customer will be grateful to you if, once having received a link to a project, at any time he will be able to see what state your project is in and what it is paying for.
So, the goal is to create a system for building projects for various platforms (web + mobile). The search led us to several existing solutions in this area:
Looking at each one, looking for the pros and cons, we stopped at the Hudson variant. This tool at that time seemed to us the most flexible and supported by the community. After we already learned that there is a Jenkins branch from him, but we didn’t switch to it. Hudson arranged everything for everyone.
We have historically chosen Git as our version control system; with it, we store versions of source codes and builds. Also, with the help of hooks, we publish current versions of projects on the test server.
And finally, for the sake of which we all started - a corporate web portal that is responsible for user access to assemblies, storing information on them and finally for being able to go in, download and test them. We called it a Publisher and this is a simple web service written by us in Python (Django). It looks like this -
')
And now more about how this all works:
At the start of the project, a repository is created for the source code and a new project in Hudson. In the project settings, we specify the address of the repository and set the settings so that the repository is polled every 5 minutes and in case of changes the assembly is launched. For Hudson, there are quite a few plug-ins that I can automatically build different types of projects, but we wanted to try everything ourselves and as a result, our build is a command line script.
The build scripts themselves are different from the type of projects.
The simplest is a web project, in this case the current version of the repository is archived and put into access.
Next, the Android project builds on complexity, here we first update the ant script (which by default is supported by the Android SDK) with the command, and then run the generated build script. For example, like this:
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 with the signature of the project for publication in GooglePlay. But, it can still be done using the command line tools using the SDK utilities.
And finally, the most interesting option - build iOS. If you use the standard method offered by Apple - you need to build the application, sign it with a developer certificate, and then install it (usually this is done via iTunes). We decided to simplify this process as much as possible. As a result, the project is built as follows: with the help of the xcodebuild utility, we compile and build the project into the app app. After that, using the xcrun utility, we sign it with a developer certificate (which lies on the build server) and send the finished apk file to the public domain.
In this case, the Target that was installed by the developer at xCode itself is collected, but this parameter can also be forcedly set.
Finally, all assemblies (ipa, apk, zip) are shared and we have a task as a user to check them. There are no problems with the web project - next to it there is a link to the test server, Android apk file can be simply 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. By reading the documentation and searching the Internet, we solved this problem. In order for the iPhone to follow the link start installing the application, this link must be of the form itms-services: //? Action = download-manifest & url = http: //server/projectname.plist There must be an xml file at this address, the structure of which is described in the documentation and which can be obtained when building a project in xCode if you check the Enterprise checkbox when packing the application. The main fields in this file are:
We automatically generate this file when we publish the assembly and now follow the Install link in our portal from the iOS device, we will see the issue of installing the application and, if we agree, see how the application is downloaded and installed.
At the moment, we have everyone involved in the project can go to our portal, download the latest version of the project and test it. And there we can publish projects of all platforms we are engaged in (Web, iOS, Android). And in the future we want to fasten there the publication of the results of the Unit testing and notification of unsuccessful assemblies.
In order to immediately explain what is special about the article, I will explain that our team had the task to build a single process for all our projects. And we have projects as mobile (iOS, Android) and web (layout, services, websites).
Introduction
At the very beginning, let me briefly explain what continuous integration is and how it can be useful.
Continuous Integration (Continuous Integration) is a software development practice in which automated assembly of products is performed to identify integration problems. Wikipedia
And if it is simpler, it is “only” the possibility, when you press one button (or automatically at all) to get a ready-made assembly of your product (application, site).
How can this be useful?
First of all, your QA department will thank you, as they will not have to tamper with the developer every hour in the hope of getting 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 integration errors in advance.
And thirdly, the customer will be grateful to you if, once having received a link to a project, at any time he will be able to see what state your project is in and what it is paying for.
So, the goal is to create a system for building projects for various platforms (web + mobile). The search led us to several existing solutions in this area:
- Hudson
- CruiseControl
- TeamCity
- Fastbuilder
Looking at each one, looking for the pros and cons, we stopped at the Hudson variant. This tool at that time seemed to us the most flexible and supported by the community. After we already learned that there is a Jenkins branch from him, but we didn’t switch to it. Hudson arranged everything for everyone.
We have historically chosen Git as our version control system; with it, we store versions of source codes and builds. Also, with the help of hooks, we publish current versions of projects on the test server.
And finally, for the sake of which we all started - a corporate web portal that is responsible for user access to assemblies, storing information on them and finally for being able to go in, download and test them. We called it a Publisher and this is a simple web service written by us in Python (Django). It looks like this -
')
Implementation
And now more about how this all works:
At the start of the project, a repository is created for the source code and a new project in Hudson. In the project settings, we specify the address of the repository and set the settings so that the repository is polled every 5 minutes and in case of changes the assembly is launched. For Hudson, there are quite a few plug-ins that I can automatically build different types of projects, but we wanted to try everything ourselves and as a result, our build is a command line script.
The build scripts themselves are different from the type of projects.
The simplest is a web project, in this case the current version of the repository is archived and put into access.
Next, the Android project builds on complexity, here we first update the ant script (which by default is supported by the Android SDK) 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 with the signature of the project for publication in GooglePlay. But, it can still be done using the command line tools using the SDK utilities.
And finally, the most interesting option - build iOS. If you use the standard method offered by Apple - you need to build the application, sign it with a developer certificate, and then install it (usually this is done via iTunes). We decided to simplify this process as much as possible. As a result, the project is built as follows: with the help of the xcodebuild utility, we compile and build the project into the app app. After that, using the xcrun utility, we sign it with a developer certificate (which lies on the build server) and send the finished apk file to the public domain.
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 at xCode itself is collected, but this parameter can also be forcedly set.
Finally, all assemblies (ipa, apk, zip) are shared and we have a task as a user to check them. There are no problems with the web project - next to it there is a link to the test server, Android apk file can be simply 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. By reading the documentation and searching the Internet, we solved this problem. In order for the iPhone to follow the link start installing the application, this link must be of the form itms-services: //? Action = download-manifest & url = http: //server/projectname.plist There must be an xml file at this address, the structure of which is described in the documentation and which can be obtained when building a project in xCode if you check the Enterprise checkbox when packing the application. The main fields in this file are:
<!-- ipa --> <key>url</key> <string>http://server/distribs/prokectname.ipa</string> <!-- --> <key>bundle-identifier</key> <string>ru.handh.projectname</string> <!-- --> <key>title</key> <string>ProjectName</string>
We automatically generate this file when we publish the assembly and now follow the Install link in our portal from the iOS device, we will see the issue of installing the application and, if we agree, see how the application is downloaded and installed.
Conclusion
At the moment, we have everyone involved in the project can go to our portal, download the latest version of the project and test it. And there we can publish projects of all platforms we are engaged in (Web, iOS, Android). And in the future we want to fasten there the publication of the results of the Unit testing and notification of unsuccessful assemblies.
Source: https://habr.com/ru/post/175203/
All Articles