ACA Blog

ACA Blog


December 2018
M T W T F S S
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Categories


6 steps to extensive Titanium App Build Automation

Yakup KalinYakup Kalin

Our colleague Yakup Kalin has recently written a blog post for Appcelerator’s blog website. You can read that post here. However, we wanted to put Yakup’s know-how a bit more in the spotlight and decided to post the article here as well.

As a Mobile Solution Expert at ACA IT-Solutions, I’ve been using Titanium to build cross-platform native apps for a couple of years now. When I first tried Titanium, its low threshold amazed me. Using languages from the web (JavaScript, XML and TSS (enhanced CSS)), I’m able to create mobile apps for Android, iOS and Windows in just minutes. In addition to that, the extensibility is just great. You can extend your codebase with ‘modules’ developed in the specific native language (Objective-C/Swift, Java, …).

Within our projects at ACA, we mostly create modules for bringing and/or enhancing existing native SDKs (e.g. Bugfender) to Titanium. And to make that even easier, Appcelerator introduced Hyperloop. Hyperloop allows you to access native code directly, eliminating an extra intermediate module layer. Clearly, with Titanium, you’re backed well for developing mobile apps.

But enough talking about the development part. There are some other crucial parts within the mobile app lifecycle, such as testing and launching, we should definitely talk about…

Testing and launching is NOT time-consuming or complicated

Everyone within the mobile world knows that test and launch steps are extremely important. However, they can also be time-consuming and in some cases very complicated. To give an example: if you Google “provisioning profile issue”, you’ll find 13.9 million results. And that doesn’t even include running tests on your codebase, testing on different devices with different screen sizes or preparing an app for a specific environment (DTAP)!

But testing and (test) launching doesn’t have to be this way. In order to prove that it can be hassle-free, I’ll share the advanced mobile app build automation process we set up at ACA with you. This mobile build automation allows us to increase efficiency and lets us focus more on the aspects within mobile we value the most: creating and delivering value for our end users. It also makes it possible for us to prepare multiple tested builds created from analyzed and validated codebases, that are ready to be (beta)distributed to users with the push of a button! So how does it work? Let’s take a look.

Mobile build automation, a high-level overview

The image below shows a high-level view of the build automation steps our Titanium apps are going through. Based on this image, I’ll go through this automation process step by step.

This image shows a high-level view of the build automation steps our Titanium apps are going through.

1. Preparing the codebase

Jenkins is our build automation server.Our journey starts right after the build process is triggered, typically automatically by a timer (twice a day) or manually by a developer. Our automation server (Jenkins) guides the whole process by triggering a Maven build. Depending on the configuration, the correct environment properties are injected within the Titanium codebase (e.g. backend URL, app version and analytics ID in our config.json). This all happens within our Mac Mini (OS X) we configured as our Jenkins CI Slave. We chose a Mac Mini for several reasons, but mainly because it offers the required mobile tools (especially Xcode for iOS apps) for building apps.

2. Unit testing with TiUnit

In our build automation process, we rely on TiUnit (which we created) for writing our unit tests.Once those variables are in place, unit tests are triggered and run automatically. We rely on TiUnit (which we created) for writing our unit tests. TiUnit, based on Jasmine, allows us to write and run tests insanely fast without having to depend on the Titanium runtime. You can find more about TiUnit on our GitHub. After those tests, a code coverage report is generated. We’re using Istanbul as our code coverage tool.

3. Analyzing the codebase quality

In our build automation process, we use SonarQube for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities.Along with the code coverage reports, a SonarQube code quality check is performed. SonarQube is a platform for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities.

Screenshot of our build automation process in SonarQube

4. UI testing on real devices

Amazon Web Services (AWS) platform for build automationAmazon Device Farm for testing multiple devices in our build automation processOnly when those tests succeed and reports are generated, then the build (bash) scripts trigger the Titanium CLI to build the app (both Android and iOS). Right after the builds are available, they’re pushed to simulators and physical devices for UI testing. Since there are limitations on simulators/emulators (e.g. no iOS camera on a simulator), we integrated with Amazon Device Farm to test our apps on real devices. With this Amazon integration, we can run UI tests and validate the behaviour of our apps on exotic/old Android devices, which is sometimes hard to achieve with emulators. Besides, buying all those Android devices wouldn’t be a healthy option anyway. If you want more information about the AWS Device Farm integration, you can check the AWS developer guide.

Amazon Device Farm results in the build automation process

5. Archiving and sharing the artifacts

Sonatype Nexus for archiving and sharing the artifacts in our build automation processOnce we get our test results from Amazon along with device logs and video/images, Jenkins triggers our build scripts again to initiate the (test) launch. Based on the configuration, development, ad hoc or release/production builds are generated and signed. After the signing, the builds (.ipa / .apk) files are pushed to our internal Nexus Repository Manager for archiving.

If desired, those builds are also automatically published to our invite-based beta distribution tool for providing apps to users for beta testing.

6. Sending notifications

Our development team is notified by email and/or by an Atlassian Hipchat notification concerning the build status in the build automation processIf all goes well (or badly), our development team is notified by email and/or by an Atlassian Hipchat notification concerning the build status, which can also be forwarded to our smartwatches.

Screenshot of HipChat notification concerning build automation

Takeaway for build automationLong story short: the takeaway

As stated above, the test and (test) launch process within mobile development can be time-consuming and, in some cases, very complicated. But it is possible to make it hassle-free. The key thing here is to automate steps that are very time-consuming and error-prone for you (and your company). To help you with this automation, there are a lot of tools out there, each with their own pros and cons. It’s important to find the tools that suit your environment, setup and/or budget. Hopefully, the tools listed within this blog post can help you achieve your own mobile build automation!

There a lot of other interesting points such as building multiple app flavours not covered within this blog post – I’ll be happy to cover them in a future blog post. If there are any focus points you’d like to see covered next time, please leave a comment!

If you’d like to read more about mobile development from us, check out these blog posts.

As a Mobile Solution Engineer at ACA IT-Solutions, Yakup is involved in agile mobile development, where he delivers creative input for realizing usable and likeable mobile applications. With a huge interest in mobile technology, Yakup develops Native, Hybrid and Responsive Web Apps.

Leave a Reply

avatar
  Subscribe  
Notify of