You start with one iOS app and then it morphs into multiple apps, and you are shipping a new version of all these apps frequently to the app store without compromising on quality. How do you do it?
First, you build an application architecture that supports the scale – a large team of developers working on same codebase and flexibility and ability to expose new features quickly to the users. Then, you invest in test automation to have multiple sets of tests for different workflows and features in your app. And, you invest in CI and CD infrastructure that eliminates wait times for developers between builds, faster feedback from tests and quick deployment to the app stores.
In this blog we will focus on how you scale and manage iOS CI build/test infrastructure to support a high velocity of development and increased code quality for releases.
We see users adopting one of three approaches to address the scale challenge of iOS CI infrastructure and introduce a new method outlined in Option 4.
Option 1 – Increase the bare metal mac hardware capacity for build and test machines
This results in increased hardware costs, but also means significantly higher system management overhead. Devops and system management team need to plan for additional complexity in build and test environment configuration management across all the hardware, capacity planning and sharding strategies to test concurrently on multiple versions of application dependencies. Due to imaging-based approach, repeated set of these operations on the same hardware also results in stability issues.
Option 2 – Consuming hosted CI iOS build services
These services are provided as multi-tenant/shared basis and in most cases unable to meet the extensive scale requirements of a single user. Additionally, there is an exponential increase in cost as the usage goes up. You are no longer in the lowest/cheapest service tier but have to move to a custom tier.
Option 3 – Scaling with legacy based virtualized infrastructure
There are some supported and(some unsupported) approaches to set up a virtualized infrastructure on top of Mac hardware which can be used to spin up iOS build and test environments on-demand. The underlying technology to virtualize in such case uses a shared storage infrastructure to support scale(more than one host). With base VM images stored as snapshots in shared storage, new instances of a VM and all the build and test job IO operations execute on shared storage infrastructure. This places extremely short response times demands on shared storage and can only be achieved at a very high cost, low latency shared storage architecture. As you scale up this infrastructure, the prices for shared storage increases exponentially. The long-term TCO of should be considered before starting with this option.
Option 4 – Setup cloud/virtualized infrastructure which can scale linearly and operates as infra-as-a-code.
The concept of containers bring this concept to Linux and Windows infrastructure; however, it’s not yet possible to run macOS inside a container. Anka Build virtualization uses macOS native hypervisor framework to create and run lightweight macOS VMs. Similar to container provisioning, it provides provisioning of macOS environments from ‘macOS.app’ package in a fully programmable manner. Anka Build Cloud exposes features to store, version and manage multiple macOS images in a central registry, similar to container registry and also provides a programmable interface to pull and push these images across various host mac machines. Once the image is pulled on a Mac host machine, immutable VMs on-demand are provisioned by cloning the already pulled image and deleted after the build/test job execution. There is no need for a shared storage architecture attached to each mac host. Additional mac hosts can be added to an existing Anka Cloud setup linearly to scale the CI iOS infrastructure with minimal effort.
Get more details on Anka Build macOS Cloud architecture and registry setup at www.veertu.com.