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.
