Vince Mansel
iOS Mobile Application Development
Show Menu


November 2012
« Sep   Feb »

A Jenkins Automated Build & Test Environment for iOS App Development Part 5


Here is some more progress and learnings:

  • ShowPlan has three third party libraries that require special handling. They are not saved in the main repository and must be integrated individually.
  • Some additional scripting is required to reconstruct the project to a state where the build environment resembles the development environmnent.
At the moment, the job of building the Appirater third party is failing with:
stderr: fatal: ambiguous argument 'AP/^{commit}':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

The work up to now has been focused on geting the Jenkins git-plugin and xcode-plugin configured and working. Although the end result of full zero touch, automated build and test has not been achieved (due to third party library handling and deployment via Jenkins), these are good success points along the way, and I can pick up on this progress later.

I want to shift focus away from the ShowPlan project to accomplish the end to end task, i.e.:

  • Developer compiles and performs automatic unit test.
  • Upon passing, unit test triggers commit and push to github for code review and integration
  • (For this proof of concept, code review is skipped)
  • Jenkins picks up new changes and runs functional tests.

A Jenkins Automated Build & Test Environment for iOS App Development Part 4


This seems like inching along at the moment. The Xcode Code Signing error still plagues the process but at least it is manifiesting in a slightly different way. On the remote build machine, once the admin user’s keychain was copied to the jenkins user’s ~/Library/Keychains, the fail transformed to:

Code Sign error: A valid provisioning profile matching the application's
Identifier '' could not be found

A few more spins did not improve the situation. Another thing I noticed is the remote build machine does not have a public key for the Developer profile in the keychain so I am not clear if that is an issue, but it is worth investigating. (Not required). Also, I will check if a “valid provisioning profile” should be specifically generated for the specific app that is targeted for build on the remote build machine. (Not Required)


It turns out the jenkins user on the remote build machine was not setup completely for xcode builds on the command line. The xcodebuild command looks for “a valid provisioning” profile in the directory ~/Library/MobileDevices/Provisioning Profiles. These are not kept in the project but instead are assigned on a per MAC OSX user basis. I created the additional directory structure for the Jenkins user and manually copied the <long string of numbers>.mobileprovision file from the admin user to the jenkins user. (See StackOverflow: 4744959)

Now, Jenkins builds the project up to a point where it fails in the compile phase because it cannot find a third party library. In the original source file, that library is manually included in the project but the git commit/push from the dev machine does include it in the repository. So the next step from here is automating the cloning of the third party project.

A Jenkins Automated Build & Test Environment for iOS App Development Part 3


Here’s today’s update on results and learnings:


  • Installed Jenkins git-plugin and xcode-plugin
  • Build Now accesses remote git repository.
  • Xcode Compile fails due to Code Signing Error during Xcode

OK, so far, OK. Progress feels slow while I am learning more about the Jenkins tools, interface and “way” of life.


  • A special github user is not specifically required for Jenkins access
  • Jenkins access does require a SSH Key setup on github but that could be a re-used quantity of main user from different machine.
  • Using ~/.ssh/config is a great way to organize what build goes with what key
  • Jenkins does not support use of passphrase in the SSH authentication challenge. ssh-agent not accessible by jenkins user so this is fail. ssh-keygen becomes almost anonymous.
  • Can setup host alias to point to github hard IP but not required.
  • Projects do not specically require Deploy Keys per project at GitHub. Admin can determine if specific keys or account wide keys are need per revision build
  • Build machine requires Xcode licensing details to be specified on initial launch.
  • Repositories are transferred to $JENKINS_HOME/workspace/<Build Name>
  • Set the SCM > Branch appropriately to the build phase. For now, */master suffices for a Build Now testing and troubleshooting runs.
  • Build > Xcode > Target specifies the target within the Xcode project itself. Default is blank which suffices for now.

So at the moment, I need to solve the Xcode Code Sign Error issues. Initially, the original project had a Code Sign Error due to Provisioning Profile expiration. After renewing, and exporting the renewed certificate to the build machine, everything is green. But I suspect that Jenkins is not configured the access the keychain which was setup by the admin user. Hence the current message:


Code Sign error: The identity 'iPhone Developer' doesn't match any valid,
non-expired certificate/private key pair in your keychains 

Fail Fast Fix Faster = The FQuatro Effect


To achieve continuous integration, we must fail fast faster… in fact,

let’s make that fail fast and fix faster. Here is what I mean by that…


Fail fast – deploy automated test tools and unit testing methodologies to get feedback on code progress.

Fix faster – at every step of the process, fix issues and fail forward. At the same time, re-inject code back to unit stage for clean automation regression. This creates spin loops and the organization determines how many spin loops are in play at any one time concurrently, based on tracking, monitoring and server load/optimization.


Once unit passes, code is automatically promoted to the integration build for integration test.

In parallel with this, code reviews are processing code for feature fit and readability for gold revision.


Once a revision set is triggered, the gold revision is to a continuous integration server for new acceptance, functional

and regression tests.


Upon passing, code is automatically deployed for beta testing, or parked for full feature suite.


Upon failing, code is triaged and combed for defect and artifact investigation and fix.


The Spin Loop and the Clean Build Cycle

The team decides the amount of spin desired for current theatre. All points in the process can produce spin to create revision for fail-fix or pass-promote. The system operates on at least 2 full spins that result in a clean, repeatable, zero touch revision launch candidate. The revision launch candidate can be cataloged and stored for purposes of product launch or update. The luanch decision is the policy of the delivery team, and varies based on product set and customer attention requirements.

Here is the quick thought overview in picture format. 

A Jenkins Automated Build & Test Environment for iOS App Development Part 2


Here is progress and findings so far based on yesterdays work.


  • Purchased, picked up and installed Mac Mini
  • Installed Jenkins, configured email properties, played with creating a new job
  • Researched what others have done, re: google searches:
    • jenkins github xcode
    • continuous integration of ios apps
  • Evaluated available github and xcode plugins

So far, so good.

There are a few interesting tutorials that I will tackle today and some seemingly ready made solutions. So this project is not a reinvention or pioneering, but it will prove valuable to get my development environment automated and stable. I will document individual findings of the process as I go.

Here are some basic findings so far:

  • I downloaded Jenkins directly from the website (instead of with homebrew from command line, a popular method)
  • Mac OS X 10.8.1 is preinstalled on the Mac. Java 1.6 was not. The installation from the .dmg package starts Jenkins as a service on port 8080 automatically.
  • Setting up email on Jenkins is a snap using with SSL on port 465.

Time so far: 5 hours.

A Jenkins Automated Build & Test Environment for iOS App Development Part 1


Yesterday, I attend the Mobile Test Summit 2012 in San Francisco. It was a great event. Listening to the speakers talk about a range a technologies and approaches, it occured to me that I could really benefit from an additional layer of automation in my freelance development enviroment for ShowPlan and other projects. So while I have a break in the ShowPlan development activities (I re-submitted ShowPlan to the AppStore to fix a submission bug in reference to guideline 11.3), I am tasking myself with architecting and deploying an automated build and testing enviroment.

From the project side, here is what I want to accomplish:

  • Use this project as a Proof of Concept
  • Learn by doing, experimenting and documenting my findings
  • Treat this as Hacker Quest (aka: a Vision Quest with a Hacker mindset) with a 4 day time limit
  • Follow a Rapid Learning Process, (i.e. investigate, learn on the fly, deploy and implement, iterate)
  • Prepare to teach others about the process, learnings, results and pitfalls.
  • Do a first hand analysis and evaluation of tools and technologies being used by leaders in the field
  • Blog at least once daily about the process, and definitely blog about quick successes and learnings

In terms of technologies, here is my initial approach before diving in

  • Use Jenkins for Continuous Integration
  • Deploy on a Mac Mini platform for automated build and test (for a freelance team of 1: this will be plenty. More about scaling to dev teams of 10, 100, and 1000 later)
  • Develop on a MacPro (already in place)
  • Unit Testing with SenTesting
  • Trigger automated for functional and integration testing after dev build passes unit test and commits to main github repository
  • Automate blackBox testing with a combo of Selinium, Appium, Bwoken, Calabash, Cucumber, Frank. (This is the evaluation part to see what can “attached” to the automation environment)

I will not focus on any new features of ShowPlan. With that, I plan to test ShowPlan’s use of ios-Trello API Wrapper so this will likely involve automatically building a new project from scratch, populating the project with its ShowFlow, Scenes and Production Elements, then pushing that ShowFlow to Trello for Sharing. To verify this integration, the automated test will need to access data from   Trello (board, lists and cards) and compare that information plucked out of the ShowPlan project CoreData store.

OK. Enough said. Off to the Apple Store to pick up the Mac Mini (2.5 Ghz/500MB/4GB)