Running a macOS cloud on mac mini cluster for iOS CI

It’s been twelve years since the introduction of the first Mac mini. During these twelve years, there have been multiple updates and new models introduced with the last one in 2014. In 2011 the Mac Mini was updated with the power of i5 and i7 processors, and users started using it for the first time in a server capacity, namely as chat, web, mail servers. Then, 2012 Mac mini had exciting updates and demonstrated significant improvement in benchmarks from 2011. 2012 model is still very widely used since it was the last model with a quad-core processor.

When iOS development took off, Mac mini became the hardware of choice for app development because of it’s small form factor and the power it packs in this form. First, it was individuals developing iOS apps, then as the complexity of apps increased, the size of iOS development teams also increased. Teams started implementing DevOps and continuous integration and testing to keep up with the increased frequency of commits. Mac mini was again hardware choice for CI because teams could stack a bunch of these and get a build/test cluster going.

What’s happening now is that there is no end in sight for the richness of features you see in the mobile applications. “iOS First” philosophy still holds healthy for the majority of mobile application development. As a result, iOS development teams are finding themselves having to build more agile and flexible build and test infrastructure that can scale with the exponentially increasing number of UI regression tests, commit frequency, shorter update cycles and a gradually growing matrix of iOS device types.

In this blog, we will describe how you can configure your existing iOS build/test Mac mini hardware into a macOS cloud and operate CI in a docker like fashion.

  • Instant start (quick boot) multiple macOS VMs on-demand from a suspended state to run jobs in parallel.
  • Eliminate the complexity of SAN and other challenges associated with management of traditional virtualization platforms.
  • My example setup consists of 2 dual-core Mac minis(which are hosted in Macstadium). My CI system is Jenkins and I am using the Kickstarter open source iOS project to demonstrate build/test job example. If your CI tool is not Jenkins but some other on-prem tool like TeamCity or hosted tool like Buildkite or Gitlab, contact us to get more details on integration. We are working to release more pre-packaged integrations with other CI tools.

    Start by signing up for Anka Build 30 day trial software at www.veertu.com. You will receive an email with links to download the following Anka Build modules.

    Anka Build package – Mac application package which you will install on your Mac minis. Anka Build package is the virtualization hypervisor (lightweight 41MB package).

    Anka Controller – This is the Anka Build macOS cloud management module packaged as an ubuntu docker container.

    Anka Registry – This is similar to docker registry and is used to store and manage the macOS VMs and versions you build for your CI jobs.

    Anka Build Jenkins Plugin – This is the pre-built plugin available for download from Jenkins plugin center to easily integrate with Anka Build macOS cloud.

    Once you have installed all the above components, you should see the following:

    Anka Build macOS cloud configured in your Jenkins master instance

    Anka Build Jenkins Plugin



    Anka Build macOS cloud of 2 Mac minis(Data accessed through controller REST API)

    Anka Build Controller Node list



    Anka Build macOS cloud access to VM templates in Anka Registry

    Anka Build Controller Registry access REST API



    Anka Build Registry displaying versions of a VM template

    Anka Build Controller Registry VM Template Describe REST API



    Starting multiple iOS jobs to execute on the macOS CI cloud in Jenkins



    Three VMs are launched from VM template and instantly started on a cluster of 2 Mac mini nodes

    Quick boot/Instant Start for macOS VMs

    Anka Build Controller display VM list REST API output



    Displaying access through VNC to VMs launched on the Mac mini macOS cloud

    macOS VMs



    Highlights
  • Scale the macOS cloud by joining new Mac minis with Anka Build package installed to the Controller.
  • Use anka run to fully automate bootstrap/pre-configuration of build/test macOS VM templates. Check anka run documentation here.
  • Configure macOS cloud on on-premise or hosted Mac minis.
  • Launching build/test environment for iOS CI jobs at AWS instance launch speeds

    In this blog, we will describe how teams can configure a private (on-prem or hosted) cloud and instantaneously launch on-demand, isolated build/test instances to execute their iOS CI jobs, while still meeting the tough demands of the speed of overall execution of the CI jobs.

    It’s no secret that speed of CI job execution directly impacts developer productivity and you see developer productivity teams making this one of their top priorities. There are multiple variables that impact the speed of execution of the CI jobs – provisioning time for the environment, seeding the environment for the CI job (config mgmt etc), performance in the environment and getting build/test artifacts in and out of the environment.

    If you look outside of macOS dependent development, most of the CI process is happening either in private or public clouds. In these setups, (taking the example of AWS) launching an instance on-demand is super easy, completely extensible and fast. Just start one with an AMI and you have an isolated Linux instance available. Containers make it even easier and more replicable. However, the story is quite different for macOS dev environments for CI.

    Existing virtualization approach to creating a macOS dev cloud on Mac hardware is based on the same solution available to virtualize Linux and Windows. However, since this technology is not optimized for a macOS cloud use case, it suffers from challenges of scalability and manageability and only supports specific mac hardware.

    In the Anka Build solution, our goal was to make sure that these challenges are addressed and that it provides the same level of agility and scalability as one would get from using AWS. So, Anka Build packages a virtualization software that can run on any mac hardware, is built on top of macOS native Hypervisor Framework, exposes an extensible CLI.

    Let’s look at the method of provisioning or launching macOS VMs on-demand in Anka Build.

    Step 1 – Create your macOS Anka VM (this will be your template) and seed it with all your build/test dependencies using Anka CLI. This will ensure that no time is spent on preparing the dependencies in the environment for when a job runs.

    Step 2 – Put this Anka VM (template) in an ‘Instant Start’ State. It’s called `suspend` state in Anka CLI. This will ensure that when your iOS CI job requests an environment, the macOS Anka VM will be available instantly for execution, without any boot time issues. It will also ensure that you always get the same, consistent instance for repeated execution of the same job.

    Demo Video for Instant starting Anka macOS Vm from a suspended state.

    Step 3 – Push the suspended Anka VM to Anka registry.  If you need different flavors of build/test instances for different types of CI jobs, then, create and push different versions of same Anka VM template to the registry and use them by referring to a specific tag in your jobs. You can also create additional Anka VM templates(for when you need different macOS version) and push them to the registry and use them for your CI jobs.

    Step 4 – Install Anka Build mac application on all your build and test mac hardware and join them to Anka Build controller.

    Step 5 – Integrate your CI system to Anka Build controller through one of our existing plugins(Jenkins) or through REST APIs. Anka Build controller will now launch one or multiple macOS VMs on-demand across your build and test mac hardware, based on your CI job requests and your jobs will execute instantaneously.

    Step 6 – Trash the macOS Anka instances or keep them for troubleshooting. Get consistent, isolated instances for the next job execution.

    Step 1 and Step 2 address the tough demands of developer productivity teams to provide faster provisioning time of the macOS build/test instances in a macOS cloud for CI and enables them to keep build and test queue moving along with increased speed, efficiency, and determinism.

    Anka Registry available in a Mac Application Package – Store and manage Anka VMs in macOS cloud for CI

    Anka Registry enables management and distribution of macOS development environments (macOS VMs) across developers and to macOS cloud for CI, for consistent and repeatable build and test operations. With Anka Registry, you can create macOS image and then in an incremental manner provision Xcode, final dependencies and push to the registry, from where it is distributed on-demand to create build/test instances to execute CI jobs.

    Furthermore, you can pull a specific version of your build/test image, make changes, clone it to a new image and start managing it again with Anka Registry.

    When you install Anka Build to set up a macOS build/test cloud, you also set up Anka Registry, which runs as Ubuntu service in a docker container or in a Linux VM. With today’s release of Anka Registry Mac application package, we are making it easy for DevOps and iOS developers to quickly set it up on their Mac machines for testing purposes.



    You can very quickly get started with Anka, by installing Anka Flow or Anka Build package on your Mac and then install the Anka Registry. Use `anka create` command line to create your macOS dev image and push it to the Anka Registry and start managing and distributing it amongst team members.

    Let us know your thoughts on how we can improve it further.

    Configuring Jenkins to scale iOS CI on macOS cloud with on-demand slaves

    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 fail 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 instances 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 Jenkins – Anka plugin (current version is 1.6). This plugin code is also available on GitHub at https://github.com/veertuinc/jenkins-anka-ci.

    Anka Jenkins plugin

    Anka Jenkins 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 https://ankadoc.bitbucket.io/using-controller/#controller-rest-apis.

    Anka jenkins plugin

    Anka jenkins plugin setup 2



    Step 3

    Define one or many slave template definitions for your iOS build/test jobs.

    Anka Jenkins plugin setup 3

    Anka Jenkins plugin setup 3



    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.

    Anka Jenkins plugin setup 4

    Anka Jenkins plugin setup 4



    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.
    Anka Jenkins plugin setup 4.1

    Anka Jenkins plugin setup 4.1



    You can now store and manage reproducible environments for iOS CI jobs.

    Step 4

    Assign slave template label to your jobs/pipelines.

    Anka Jenkins Plug Step 4

    Anka Jenkins Plug Step 4



    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.

    Anka Jenkins Plugin step 5

    Anka Jenkins Plugin step 5



    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.

    Using Anka to Build Anka – Example of developing locally on workstation in build and test Anka macOS VMs

    Here is a peek into how our development team uses do builds for Anka product locally using Anka itself. We have all seen multiple blog posts shared by developments teams who are developing on top of Linux explaining how their developers are using containers to setup build and test environments locally on their workstations, with all upstream CI dependencies. This eliminates the “But, it works on my machine” issues, reduces failures in the upstream CI process, make it easy to reproduce environments for debugging resulting in greater velocity in application development and release.

    But, most important of all, it provides flexibility to developers to install and play with newer packages, frameworks on their machines without having to worry about breaking things with the mainline application build, test, and release process.

    Our development team is enjoying the same benefits while building Anka product. Since Anka is for development on the macOS platform, we are doing local builds during development inside Anka on developer machines.

    Like many development teams out there, we have set up a central CI to do automated and manual builds and testing for minor and major releases of Anka Flow and Anka Build products. We do CI builds inside Anka virtual machine environment.

    However, we also do a large no of internal releases to continuously try and test new things and quickly address user issues. This is largely due to two things – First, Anka is new technology and as it’s getting adopted by users there is a lot of development activities taking place to address user requests, fix bugs etc and second, in the past 2-3 months with macOS Sierra to macOS HiSierra transition, we had to continuously keep pace with all beta updates. What this means is that our developers need agility to build Anka packages locally with their changes, without having to wait for it to go through the upstream CI pipeline.

    In normal circumstances, this would be impossible because of a complex matrix of dependencies that are needed to do a release build. However, because we were already doing our CI builds in reproducible Anka macOS VMs using Anka Build, our developers just pull the latest version of build VM (build_vm2(sep 5)) from the Anka Registry on their machines and run their builds inside that environment (anka run build_vm2 ./build.sh). The output Anka Build and Anka Flow application packages are available on their local machines. We use a fairly large number of external libraries and packages in our application and having them all packaged in Anka build VM that is maintained by our DevOps, frees up the developer to have whatever they want on their laptops. Our developers very quickly transitioned to HiSierra and started working with Xcode 9, while we were still compiling and building Anka on Sierra and Xcode 8.3.3.



    Step1 – pull `build_vm2` from Anka registry on local machine



    Step 2 – Build locally with `anka run` inside build_vm2 Anka VM



    Anka version update 1.0.2.73 for HiSierra GA release support

    We are publishing an updated version 1.0.2.73 for both Anka Build and Anka Flow packages. For the past two months, we have been testing Anka with the HiSierra macOS and have supported the HiSierra beta versions. Today, with this release update, we are supporting the HiSierra GA version.

    Some of the things that you can do specifically for HiSierra are as follows:

    1. Run Anka packages on machines running HiSierra macOS and create and run HiSierra Anka VMs.
    2. Create HiSierra Anka VMS and run them on top of Sierra machine


    In addition to HiSierra related fixes, this release includes fixes to additional issues reported by our users. Download the new packages from the download page or contact us at support@veertu.com to get details on the download.

    https://ankadoc.bitbucket.io/release-notes/

    Deep Dive into Anka Registry – Version and Distribute macOS virtual machines at scale

    One of the key differentiators in Veertu’s Anka solutions packages (Build And Flow) is Anka Registry for macOS virtual machines. When you look at current DevOps workflows for development on Linux, containers significantly increase CI efficiency by ensuring consistency across multiple developments and release cycles with repeatable development, build, and test environments. For individual developers, containers eliminate the “it works on my machine” problem by ensuring parity for the entire team. This parity exists across the entire environment, on CI, and on the developer machine.

    Containers achieve parity with a common repository that contains the artifacts which can be used to build and run container images in a host-agnostic manner and through version management. Anka registry architecture maps this design to managing and distributing environments for development on macOS platform.



    macOS natively doesn’t support the concept of running macOS containers and layered container image architecture, however, with Anka Registry we were able to superimpose the registry-based workflow on macOS VM architecture.

    Let’s look at how Anka Registry achieves this. When you set up a macOS private cloud with Anka Build virtualization and cloud components, you also set up Anka registry module. Anka registry is a Ubuntu service written in Go. It’s packaged to run as a Docker container for easy deployment, but you can also run it on an Ubuntu VM or any other Linux flavor. It supports both HTTP and HTTPS communication between the registry backend and client. HTTPS is configured with NGINX.

    After deploying Anka Registry, engineers can push macOS Anka VMs from the machines running the Anka client package (Anka Flow or Anka Build). In traditional VM storage concepts that exist today, the entire VM is packaged, copied over, stored and managed. This fails to provide benefits of efficiently managing images for dev/test and ensuring consistency across all systems. Anka Registry `push` breaks the macOS VM into the VM configuration and into delta image files. First time push for a macOS VM moves over the VM configuration and the entire VM together. Any subsequent changes to this Anka macOS VM get tagged for version management, and registry `pull` analyzes the VM images and moves only the deltas. The result is a significant reduction in the network requirements and a swift push operation.

    Anka also provides the ability to “Instant Start” macOS VMs, which is critical for when you want to set up on-demand provisioning for macOS VMs for development and test CI jobs. For these operations, Anka Build works with macOS VMs stored in the suspended state in the Registry. Things get very interesting when you push and pull suspended-state VMs. In addition to managing the deltas in images for the macOS VMs, with suspended VMs Anka Registry also maintains the state of the VM so that when it’s pulled, it comes over in the same state and is available right away for job execution.

    Anka registry pulls also operate similarly to registry push. The first-time pull of an Anka macOS VM will get the entire VM configuration and images. Any subsequent pull request for the same VM analyzes the dependencies and pulls only the deltas.



    More optimizations occur when you clone Anka macOS VMs and store and manage them in Anka registry. Registry pull and push use the same concepts of managing deltas and dependencies to reduce the overall footprint on client machines and provide flexibility for easily reproducible macOS environments that start instantly.

    We are working on some other exciting ideas for the future roadmap, which will bring this concept even closer to a real container architecture for creating and managing macOS environments for development test. Stay tuned.

    Moving from static iOS CI infrastructure to an agile, scalable macOS private cloud

    In this blog, we will describe the path to move from static, physical hardware-based build and test iOS CI infrastructure to one that is agile, scalable, and enables infrastructure-as-code for macOS. In short, you will be able to setup an AWS-like self-service macOS private cloud to run your iOS CI jobs in container-like environments to support your iOS developers.

    After a broad survey of existing blogs on iOS CI and discussions with multiple iOS development teams, we have reached the following conclusion on the current state of iOS CI infrastructure.

    There are only a handful of ways in which teams that are doing on-prem iOS CI (not just builds, but build and automated tests followed by continuous deployment) can set up their macOS infrastructure to support the iOS CI pipelines/jobs. This limitation exists not due to lack of intention to have a more flexible cloud setup, but due to a lack of availability of cloud technology for enterprises to set up macOS dev/test private cloud, which can also extend to iOS developer machines.

    Let’s compare and outline the steps to move from existing status quo to a dynamic, infrastructure-as-a-code setup for development on the macOS platform.

    iOS CI on Physical Infrastructure Anka Build Cloud iOS CI Infrastructure
    Hardware – Mac hardware allocated for Build and test. Hardware – Mac hardware allocated for Build and test.
    Prepare the hardware – Keep the macOS versions/updates consistent on all the CI machines. Some users do it with periodic re-imaging. Re-imaging is no longer needed, simply run software update to take advantage of the latest Anka features.
    Prepare the machines to act as a build/test node – This step requires installing all dependencies etc. Most users run configuration management tools on CI mac hardware for this. Install Anka Build.pkg on all Build/Test mac hardware, henceforth called Anka Build nodes.
    Create macOS Anka VM and provision (installing dependencies) for the CI jobs. You can fully automate this step with ‘anka create’ & ‘anka run’ (even use existing config mgmt scripts).
    Version and push the macOS VM prepared in the earlier step to the Anka registry.
    Install and setup Anka Build Controller module on a linux machine or container.
    Join all Anka Build nodes with the Anka Build Controller.
    Add the prepared build/test node to the CI system. Setup Anka Build cloud in CI system of choice (For Jenkins, use Anka plugin).
    Every execution of Build/Test CI job first baselines the configuration on the build mac machine and then starts the actual job. Build/test CI job sends a request to Anka Build controller to pull from the registry and provision clean and sandboxed copies of Anka VMs on the Anka build nodes. VMs are preconfigured with all the dependencies.
    After job completion, the machine is left in dirty state. After job completion, the VM can be deleted with no traces left on the hardware or kept alive in an isolated state for debugging.
    Next job execution consumes job cycles cleaning the machine first, before running the job. Next job run just provisions clean pre-loaded Anka VMs of particular type, pulled from the registry.
    Any issues in configuration management during job runs can result in inconsistent build/test environments. Anka VMs are preloaded with all dependencies for a consistent, immutable environment every time.
    Total job time for every run gets extended due to the necessity to run configuration management to prepare the environment with all the dependencies. Total job time is actual build/test time with no overheads. First-time pull of a particular build/test Anka VM can be time-consuming, but this can be resolved by “warming up” the Anka Build nodes (pre-warm the Anka Build node by pulling the VM ahead of time).
    Any update to dependencies means tweaking configuration management scripts, with no recourse to go back for troubleshooting. Any update to dependencies means, pulling the last good Anka VM build/test environment from the Registry, updating it with new dependencies and pushing it back to the Registry with a new version. Easy to pull an older version to troubleshoot issues or revert to a previous version of infrastructure.
    Not easy to replicate the same CI config mgmt on the developer machines. Eliminate “Works on my machine” issue, with developers pulling the same build/test Anka VMs (reproducible envs) from the Registry and using them to build and test on their workstations locally.


    Notes:
    • Anka Build product contains all software modules to setup and configure macOS private cloud for iOS CI.
    • Anka Flow product contains all software modules to enable iOS developers to have the same consistent build and test environments as the CI system.
    Start with Anka Build first and then, add Anka Flow.

    Veertu Anka GA Announcement

    Today, we are pleased to announce the General Availability of Veertu Anka Build and Anka Flow(formerly Anka Run) r1.0.0.61. Release 1.0.0.61 is an update to Anka Beta r1.0.0.47 which includes all features delivered in previous beta versions, as well as updated features and fixes.

    We are extremely grateful to our beta user community who helped us evolve Anka Build and Anka Flow products. GA Release 1.0.0.61 includes a majority of beta user feedback and we will continue to review the feedback for future product roadmap.

    Anka Build and Anka Flow fill a very critical gap in the macOS and iOS development process. With Anka Build, Devops can transform a cluster of Mac hardware to a macOS build and test, self-service, private cloud. This can be further integrated with existing CI system for iOS and macOS CI process.

    Anka Flow, is a container like set of tools to setup local build and test macOS environment for iOS development. Both Anka Build and Anka Flow are built on top of Anka native macOS virtualization technology, which runs macOS VMs on top of macOS hardware.

    Getting Started with Anka

    Users can start with a 30 day trial of Anka products. Trial includes all the components to setup a self-service macOS private cloud for iOS/macOS CI as well as local developer environments. There are no restrictions on the number of build and test macOS machines or developer machines for the trial. Trial license will be generated for the machine count provided at the time of registration.

    How to upgrade from Beta Version

    In order to continue testing of Anka, beta users can register for a 30 day trial. After obtaining the trial license, install Release v1.0.0.61, activate it, upgrade other components and continue with the testing.

    Configuring iOS real device infrastructure for in-house parallel mobile test execution

    Agile development is putting a lot of pressure on traditional CI and testing approaches. It demands faster build and test times so that feedback can be provided quickly to the developers. It also assumes that test system related issues shouldn’t slow down CI pipelines and that tests in isolated, sterile reproducible environments offer the most reliable feedback. For mobile projects, that can also mean performance testing on real devices as well.

    Let’s look at the particular case of testing iOS applications on real devices in CI. Execution time for tests is very critical, and testing on multiple devices sequentially would take a long time. The problem gets worse with a lot of test executions and the requirement to keep pace with rapid build frequencies. If the budgets are limitless, then hosted device farms are a great option. Most often teams discover that unlike other cloud services which have gotten cheaper over time, hosted device farms prices don’t come down, but only increase. It’s because new devices get added, and the frequency of test execution keeps growing. As a result, the total cost can get pricey. Additionally hosted device test farms may not benefit the security posture of some organizations that want to secure the protection of their intellectual property.

    The approach users take in this scenario is to connect as many iOS devices as possible to available macOS hardware and run test sequentially through CI. But, anyone who is doing this is familiar with the challenges of maintaining and automating test execution on such an infrastructure. They include but are not limited to–cleaning up after a test, starting a new test in a sterile setup, executing tests in parallel on multiple iOS devices (not an issue in newer Xcode version) and more.

    One alternate approach is to launch a clean macOS VM which has an iOS device connected for every test execution. Each test run gets a sterile environment and environments with particular test tool settings can be consistently reproduced for very execution. When you build a macOS self-service on-premise cloud with Anka Build, you can programmatically manage and automate association of physically connected iOS devices to macOS VMs for running parallel iOS real device tests.

    Anka Build exposes the ability to manage iOS device association with the dynamically provisioned macOS VMs through a command line interface and enables automation of this task. Then, it can easily integrate with the existing iOS CI process.

    How does it work?

    Let’s say that you have a cluster of centralized build/test Apple machines (on-premise or hosted).

    Step 1 – Connect one or more iOS devices to these machines.

    Step 2 – Create a group using `anka usb-group` command. The Anka USB group feature eliminates the need to pre-define/attach individual iOS devices to test environments. A dynamically provisioned test environment/VM can, at run time, get a free device from the USB group (think of the group as a pool) attached to it, execute the test and release the device for use in the subsequent test.

    Step 3 – Add the iOS devices to this usb group.

    anka usb-group --help

    Usage: anka usb-group [OPTIONS] COMMAND [ARGS]...

    manage usb device groups, and you can attach a group to a vm so the vm could pull an available usb device from that group

    Options: --help Show this message and exit. [optional]

    Commands:

    add-device : adds a device to a usb group, if the group...

    create : create a new usb group

    delete : delete a usb group and release all it's...

    list : show all usb groups

    list-group-devices : show all devices that belongs to a group

    remove-device : remove a device from a usb group


    Step 4 – Attach this usb group (pool of iOS devices) to the VM using anka modify command.

    anka modify VM add usb-group --help

    Usage: anka modify add usb-group [OPTIONS] GROUP_NAME


    Step 5 – Push the VM as a base VM to Anka registry.

    Step 6 – Now, when you provision test environments with this base VM on the build host with the devices attached, the VMs will claim the first available devices from the group, execute the test and release them for the next test job execution.

    This approach provides a clean test environment setup for every test run, reduces the management overhead of claiming/releasing devices and offers a programmatic interface to do this automatically.

    If you would rather work with the single iOS device instead of a pool, you can use the same USB pass through Anka USB command line interface.

    anka usb [OPTIONS] COMMAND [ARGS]...

    Do actions on USB devices

    Options: --help Show this message and exit. [optional]

    Commands:

    claim : make a device available for attaching to vms,...

    list : list all available usb devices on this host

    release : release a device back to host availability,...

    anka modify add usb-device [OPTIONS] DEVICE_IDENTIFIER


    For detailed information on how to setup a self-service macOS on-premise cloud, read this Anka Build blog.