Skip to main content

Continuous Delivery with Titanium, TestFlight, Jenkins, and Nomad

Continuous Deployment for TestFlight, Jenkins, Nomad
As an advocate for continuous delivery, building native mobile applications has always been a common problem faced for developers wanting to move fast, build something, measure the results and evolve their application. Incidentally, AppStores don't really provide an easy way of following lean entrepreneurship (ship fast, build, measure, learn). Things are getting better so I've decided to blog about our experience with continuous delivery with TestFlight, Jenkins, Nomad, and Titanium.

Some of the key benefits of continuous delivery include
- Being able to avoid large integration (merging) issues when feature branches have diverged extensively from what is on production. Smaller changes going into production frequently are a lot easier to resolve (fix or rollback).
- Deployment procedures can be tricky depending on the platform and the technologies you use -- automate everything so that you don't miss any steps within your deployment procedure
- Smaller changes going into production are easier to code review, it won't take up too much of an engineer's time

The Tools

- Titanium (being a JavaScript developer, it was easier for me to write in one language and generate iOS and Android applications for a minimum viable product).
- Jenkins (running Jasmine tests via NodeJS on any controllers, responds to webhooks when master changes, and pushes iOS binaries to TestFlight API)
- Nomad (Ruby-based tool which lets you generate iOS binaries)
- TestFlight (a platform for automating beta testing specifically iOS apps, getting user feedback, and getting crash reports/device diagnostics)

The Pipeline

- When developing a feature, branch off of master `(master) git checkout -b FEATURE-XYZ`
- Write the feature, pull in master, freely push to your feature branch and Jenkins will continue to run tests on your feature branch
- When a feature has been completed, use nomad to generate the IPA, commit the generated binaries depending if your Jenkins server is Mac OS X or not, submit a pull request to master, have it code reviewed.
- When the feature branch gets merged into master, we have a webhook that fires and Jenkins takes it off of master, runs tests, then ships the binaries to TestFlight via the TestFlight Jenkins Plugin
- This will automatically email all your beta users or specific groups of beta users (you can customize this list) to install that version that was just merged into master

Lessons Learned

- When you invite new beta users, don't forget to update your Mobile Provision Profile prior to merging into master by adding the new device identification numbers -- this will make it so that when they get emailed to install a new version of your app, they won't get a rejection error.
- The installation experience for beta users whether they are technical or not is absolutely amazing.
- If you ship to production 50+ times a day, your beta users may get a lot of email spam for installing specific builds.
- You won't need to commit the IPA to source code if your Jenkins box is Mac OS X (our Jenkins box is a Windows box since the platform runs CI on .NET code)


Popular posts from this blog

TextMate Tutorial: How to add a Strikethrough keybind to your Markdown bundle

Markdown is awesome for quickly generating Readme's on Github. After looking at other projects using the strike tag, I've decided to create a custom keybind for it in my TextMate Markdown bundle. Here's how:

1) Click the + sign on the bottom left and click New Command.
2) Paste this into the editbox and make sure you name your command "Strikethrough".

For the input field, select WORD in the drop down.
For the output field, select "insert as snippet".
As for the keybind, you can totally map it to whatever you're comfortable with but I chose Command-D as it is the same thing in Microsoft Word.


Plenty of Fish - Lessons Learned Meetup

Today, I had the fantastic opportunity of going to a retrospective by Plenty of Fish. As you may know, Plenty of Fish is the largest online dating site and it was all started by a local BCIT graduate named Markus Frind.

Below are notes that were taken on my iPhone. I do apologize as I am continually editing this blogpost.

What is Plenty of Fish? An online dating site.
Why enter the dating market? Back in 2003, it was the only thing that was interesting to build. Markus already knew ASP but wanted to learn more about building web applications with ASP.NET and improve his skills on his resume. 
How do you deal with the network effects problem? In the early days, Plenty of Fish gained traction through Vancouver and Toronto.  There wasn't any silver bullet or magic around it -- Plenty of Fish heavily relied on organic user growth and SEO. The focus was to retain users more than go out and acquire new ones.
What are some early challenges you faced? Markus actually ended up doing every…

World of Warcraft Ninjalist addon: version 0.1 coming along quite nicely

After toying around with more GUI related issues in World of Warcraft's API, I've decided to take a totally different direction. Originally when I architected this addon, I knew in my mind it would be a super simple Console application that a user could easily paste in a name and add it to the database; however, why stop there?

After discovering AceGUI, I can easily start developing UI components in no time! As of right now, I've got it saving data in between game sessions--the interesting part will come when I'll have to develop the web service that will parse the SavedVariable.lua, eliminate duplicate entries, as well as, do a huge merge between their copy and whats on the server's (per realm basis of course).

Here's a screen shot of the responses when adding new Ninjas to your list:
When a user clicks add after entering a name in the textbox, it'll go ahead and add that person to the ninjalist tagging the user's realm and current date/time. Someday, I…