This blog is not a comparison of CI tools or services available. It assumes that Jenkins is your CI tool of choice for iOS CI/CD. There have been a lot of blogs written on how to configure Jenkins for iOS CI – starting with plugin installation, using Fastlane and other tools etc to further streamline the process. The last step of this workflow is the slaves on which the Jenkins iOS jobs run. In all the setups I have read about, the last step executes on macOS hardware configured as static slaves/nodes. Some of the common challenges with this static slave setup, that we have discovered through our conversation with the users are as follows.
Lack of consistent and isolated slave environments for all the jobs
Almost all iOS build/test jobs irrespective of differences in application, install multiple dependencies(internal or from public repositories). Multiple runs of these jobs pretty much require re-install or fresh install of these dependencies on the Jenkins slave mac node. Often times, the public dependencies which are directly git cloned from public repositories change between different runs of the same job, resulting in build/test failures. Multiple installs, uninstall of the dependencies can leave the Jenkins slave node in a polluted state with leakage between different job runs.Difficulty with reproducible slave environments
When CI build/test fails due to environment-related issues (for example wrong version of a specific library) the CI queue starts to build up rapidly and troubleshooting options become a great challenge. Devops/Developers can’t spend too much time troubleshooting in slave environments as it impacts the overall available slave capacity. The focus then is to quickly patch/fix and get the CI queue moving again. There is no easy way to have reproducible environments to assist in these scenarios.No flexibility to iterate changes in the environment
In a static slave node Jenkins CI setup, most often, when you have to test the CI workflow on new releases of macOS and Xcode, you have to shard the available static node capacity.These challenges can be addressed if it was possible to spin up/down macOS slaves on-demand on a pool of hardware, similar to the way you can spin up/down instances on AWS from the AMIs. However, nothing like this exists when your job needs to run on macOS and not on Linux or Windows.
At Veertu, we built a Jenkins plugin for our Anka macOS cloud technology. The way it works is first, you configure macOS cloud on a cluster of Mac hardware (hosted or on-premise) with Anka Build and create your iOS build/test VM templates. Then, install Anka cloud Jenkins plugin from the Jenkins plugin center. Once the plugin is installed, you can define your slave template definitions and associate them to build/test iOS CI pipelines or jobs. Now, when your jobs execute, they will on-demand spin up a required instance of specific macOS VMs(as defined by the label associated with the job) environments on the Mac hardware cluster to act as your Jenkins slave instances.
Below steps describe this in more detail.
Step 1 – Install latest Jenkins – Anka plugin.
This plugin code is also available on GitHub at https://github.com/jenkinsci/anka-build-plugin
Step 2 – Point the plugin to connect with the Anka Build macOS cloud.
You will need IP address of the Anka Build controller https://veertu.com/anka-technology/. Think of Anka Build controller as a central management server for your macOS cloud built on top of Anka. It exposes a rich set of REST APIs for integration with other third party CI systems. 
Step 3 – Define one or many slave template definitions for your iOS build/test jobs.
Template field in the plugin shows all the macOS VM templates that you have created. Think of these templates as AWS AMIs. These templates are stored in a central Anka Registry storage component. You can pull these VM templates on your machine, make changes to them (install new dependencies) and push them back to the Anka Registry with a new tag/version. 
All the templates stored in the Anka Registry and their versions are available for use as slave templates in the Jenkins plugin. If you don’t select a version, the plugin will use the latest version. 
You can now store and manage reproducible environments for iOS CI jobs.
Step 4 – Assign slave template label to your jobs/pipelines.
Step 5 – Now, execute one or multiple concurrent jobs.
Jenkins Anka plugin will start the required number of Jenkins slave macOS VMs of the type defined in the slave template definition. Every job executes in a consistent and completely isolated environment.
The central management server aka Anka Controller manages the request queue for slave instances and provisions instances on available mac hardware nodes in your Anka Build cluster. So, you can run concurrent jobs in Sierra, HiSierra and also different versions of Xcode on the same pool of hardware. 
Let us know your thoughts and ideas on how we can further enhance the Jenkins-Anka plugin. You can also try it out with Anka Build cloud for iOS CI with a 30 day trial of Anka Build.
