Vince Mansel
iOS Mobile Application Development
Show Menu


November 2012
« Sep   Feb »

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.