Brett McGinnis

Jenkins Adventures - Xcode edition

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.

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:

Bash

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

Groovy

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.

Image courtesy of Danka & Peter for Unsplash.

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. He applies his extensive background in applied computational and mathematical sciences to automate the systems which L4 Digital uses to test and review digital products and services prior to delivery.

Share this:

More Posts


Want Alerts When We Post New Stuff?
L4 Digital. All rights reserved. All wrongs reserved. © 2008-2017