Jenkins Adventures – Xcode edition

February 23, 2017

You should be using Jenkins pipeline to build your Xcode 8 projects.

A team member submits their code into the repository, then some voodoo magic happens and eventually you end up with unit test reports, apps built for multiple environments, a new server deployed, and notifications to the team. At L4, we use Jenkins as our continuous integration and development server (Jenkins is the magician). And while it might seem like magic at first, we’ve kept it simple, broken it down into smaller bite sized tasks, and built it in such a way so that all members of the team are able to understand the inner workings of the voodoo. One of the recent updates we’ve leveraged is the new Jenkins pipeline and integrated Xcode 8 system.

Continuous integration images of develop, build, test, release.

We’ve found the Jenkins pipeline feature helps us in two main ways. The first is with build performance. All of our code review requests (some call it pull requests) and build commits require Jenkins to do something. That something is defined by the project team but could be: running tests, compiling several app binaries, uploading packages, static code analysis, and/or notifications to Jira, Slack, email, or even the source repository of build status. Before we integrated the build pipeline, a single build would run in series, which, for some projects with a lot of build artifacts, could take hours. Awesomely, with the pipeline we are able to parallelize builds. To clarify: that means we get to build and test at the same time, or build the binaries intended for different groups at the same time (e.g. production binary vs an internal test binary).

Secondly, the update to use the Jenkins pipeline includes a move of the build configuration out of the shared Jenkins server and into source control owned by the project team. Since it lives in the source control system of the project, it allows all members of the team to contribute to the build instead of having a “build person”. Only having one build master can typically end up as a single point of failure. Also, a big win is the build scripts are versioned, so that the exact build and scripts used are traceable, and there is no more “it works on my box” ^_^. An added bonus, the build scripts can be used to teach new developers what the dependencies of the project are, leading to faster ramp up (documentation via scripting).

The language used for the pipeline is Groovy, and can be easier to maintain. A common language for builds is Bash, and I think it’s fair to say, Groovy’s readability is higher. Another way to say it, the Groovy syntax is probably closer to what a developer sees on a day to day basis. For example, something as simple as making a variable all lower case looks very different between Bash and Groovy:



 LOWER_CASE_VARIABLE=$(echo ${VARIABLE} | tr '[:upper:]' '[:lower:]') 


 lowerCaseVariable = variable.toLowerCase() 


To recap: that’s faster, simpler, and maintainable builds; not too shabby Jenkins (Nice work!). If you would like to know how to use Jenkins pipeline with Xcode projects, check out our github project made just for you! Technically this style of building Xcode projects could be adapted to other CI systems; if you find a cool, or better, way to do this, please let us know.

Brett McGinnis

Brett McGinnis is the Director of Quality Assurance and is responsible for releasing products with the high quality our clients have come to expect from L4 Digital. He applies his extensive background in applied computational and mathematical sciences to automate the systems L4 Digital uses to test and review the company’s digital products and services prior to delivery.

Opportunity and L4
Tech’s Best and Worst in 2017
Droidcon 2017: A History of Android, and a Look Ahead
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • Contact L4