How we use Podio, Fastlane, and Jenkins for continuous iOS app delivery

Published in

Podio Engineering Blog

7 min readNov 16, 2015

Here at Podio we follow agile software development practices - we write user stories, timebox tasks, do pair programming, and we iterate and refactor code. However, one practise our mobile iOS team was challenged by was continuous delivery.

If you are an iOS developer, you know the thorny path your code has to go through - from a commit to your repository, all the way until a build with the latest feature reaches your users. It is a very error-prone, time consuming, and manual process no developer ever wants to go through!

Wouldn’t it be awesome to come to work every morning and have a new build with the latest code uploaded to TestFlight? Wouldn’t it be great to always have a build ready to send out to your beta testers or submit to the App Store? Wouldn’t it improve your team’s transparency and communication if everyone could see a build status at any time?

In this blog post, I want to show you how we use Podio, Fastlane, and Jenkins to achieve all that and smooth out the iOS release process. Before we begin, I want to give you a brief overview of tools we are using:

Podio is a cloud-based workflow management tool. It allows you to better organize your work processes, so your team, and entire company, can stay in-sync and collaborate more efficiently. Podio can be used for a variety of purposes: as a project management tool, a CRM, task management, or communications platform.

Fastlane is an open source collection of tools for automating iOS (soon also Android) app release process. It enables developers to set up deployment infrastructure and focus on actual development rather than fixing homemade automation scripts.

Jenkins is a continuous integration and continuous delivery application. You’ve likely heard of Jenkins before, as it is a commonly known tool enabling teams to ease their deployment processes.

Let’s get started with a brief explanation how we manage our beta testers and builds.

How we manage our beta testers

Beta testers - we treat them as gold. They give us precious feedback on our latest work. They inspire us with new ideas and feature requests, and help us discover potentials bugs before we submit a new build to the App Store.

We use TestFlight as our app distribution channel for beta builds. We have 2 groups of testers: internal Podio employees and external early adopters of the Podio iOS app. We have Podio workspaces for both internal and external testers (read more about creating workspaces). This allows us to effectively communicate with our beta testers, gather their feedback, feature requests, and bugs.

How we manage builds

We need to know several pieces of information about a build in order to effectively collaborate and communicate across the team:

What is the build number?
What is the build status? (In development/TestFlight/AppStore)
Did all our tests pass?
Were there any bugs found in the build?

This is where Podio apps (read more about creating apps) become very handy. We have a “Builds” app where we regularly create an item for every new build and update relevant information as we go (we do not do any of this manually of course).

Our “Builds” app is composed of several fields, namely:

Text field for name — unique build name
Category field for platform — iOS/Android
Category field for status — In development/TestFlight/AppStore
Category field for unit test status — Passed/Failed
Category field for UI test status — Passed/Failed

Alright, now that we know how we use Podio to interact with our beta testers and bookkeep our builds, let’s dive into Fastlane.

How we use Fastlane

Fastlane allows us to define lanes composed of several dedicated actions. An action could be anything from making your computer say a given string (say) to archiving your app (gym) and submitting it to your TestFlight testers (pilot). Learn more about Fastlane installation and usage on Github page.

Lanes

We currently use 3 lanes:

unit_test: the goal of this lane is to run a unit test against the latest commit and provide rapid feedback to developers.
ui_test: the goal of this lane is to run UI tests and provide feedback to developers.
make_build: the goal of this lane is to build and archive (.ipa) the app, and finally, upload it to TestFlight.

Green actions are predefined Fastlane actions, while the blue actions are custom AppleScripts.

As you can see, each lane has a podio_item action. A podio_item action will create an item within our “Builds” app or update an item in case another item with the same unique identifier already exists. This action enables us to communicate with the Podio API from Fastlane lanes.

Snippet of podio_item action usage (see documentation):

podio_item(
  identifying_value: "Podio for iOS #{version} (#{build})",
  other_fields: {
    “platform” => “iOS”,
    “status” => “TestFlight”,
    “unit-test-status” => unit_status,
    “ui-test-status” => ui_status
  }
)

Firstly, we pass the identifying value: the unique identifier of an item within the “Builds” app. In the snippet above, we interpolate a string with the build number (always a unique number) for this purpose. Secondly, we pass in other field values. In our case, we have fields called “platform” and “status” (to find a field name in a Podio app go to Modify app -> Advanced -> Developer -> External ID), and give them the following string values: “iOS” and “TestFlight”. Other fields called “unit-test-status” and “ui-test-status” are given values from the variables unit_status and ui_status.

Now we know how Fastlane enables us to automate processes, and how the results are then reflected in Podio, but we are missing one part to this setup: execution. We need to execute these lanes on a regular basis, and that’s exactly what Jenkins will do for us.

How we use Jenkins

We use Jenkins CI to execute Fastlane lanes. We have the following jobs:

ios-continues job executes unit_test lane. This job is triggered with every commit to our repository.
ios-ui-tests job executes ui_test lane. This job is scheduled to trigger every midnight Mon-Fri. We intentionally did not set this job to run with every commit, because it usually takes several minutes to complete. We think this could be a little overkill and potentially block other Jenkins jobs from execution.
ios-nightly job executes make_build lane. This job is scheduled to be triggered every night Mon-Fri at 4 AM.

Putting it all together

So how does it all play together?

Every workday at 4 AM Jenkins triggers the make_build lane. At the end of this lane we have a newly created build with the latest code uploaded to TestFlight. podio_item updates the status of this build within the “Builds” app to “TestFlight”. This way we stamp the build as shipped/completed.

As part of this lane, we also increment the build number. Finally, podio_item creates a new item within our “Builds” app with this new incremented build number as its “identifying_value”. Think of this newly created item as a placeholder for the next day.

As we walk in the office the next morning, we have a new build ready and processed on TestFlight (without us doing anything). We gain the freedom of moving this build to our external testers or even submit it for App Store review at any time without delays. As we work throughout the day, the unit_test lane gets executed (triggered with every commit to repository). This changes the unit test status (Passed/Failed) on our placeholder item within Podio.

At midnight the ui_test lane gets executed. This changes the UI test status (Passed/Failed) on our placeholder item within Podio. And the workflow starts again.

Conclusion

We find the combination of Podio, Fastlane, and Jenkins to be a great mix of tools for automating our workflows. It enables us to have a new build on a daily basis. This build gets labeled during the day, reflecting the “health” of the build.

Moving forward, we plan to include sigh, snapshot, and frameit into our workflow. Moreover, we also plan to use boarding to ease the process of becoming Podio iOS beta tester.

We are very excited about the recent announcement of Fastlane support for Android. The iOS team greatly benefits from the current infrastructure and we see this as an opportunity also for the Android team.