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.

Anka Beta new version 1 Build 41 update – For self service on-premise macOS VMs

Today, we are announcing the availability of Anka Beta version 1 build 41 to all the beta users. Please check your email for the download link. New users can sign up at www.veertu.com. In this update, we have added some pretty cool feature updates to Anka macOS VMs configuration, that are directly relevant to use cases for enabling DevOps to setup a macOS on-premise CI infrastructure to test their enterprise wide deployment scripts, upgrade processes etc for Mac workstations. These features were implemented based on beta user feedback.

Check out the version 1 build 41 release notes for more details.

Let’s take an example: You are an enterprise with a large deployment mac hardware(laptops etc) being used by the employees. The portfolio of Mac hardware being used can be a mix of different models. Now, you have a set of bootstrap actions that need to take place on every employee mac or a set of macs. For example, applications deployed, permissions etc. Before rolling out any new changes to your bootstrap process, you want to test it. Because once it’s rolled out to thousand of employees, the cat is out of the bag and it can be challenging to roll back the changes if they don’t work as designed.

In this case, you can take your cluster of Mac test hardware, deploy Anka Build on it to transform into a self-service macOS cloud. Now, use this infrastructure to do CI testing of your employee mac machine bootstrap process’. Spin up reproducible, sterile Anka macOS VMs on-demand and simulate testing on different models by modifying hw.product, hw.family, hw.uuid etc. parameters for the Anka VMs.

                                           

Anka Packer Builder – To create macOS Anka VMs for iOS/macOS CI

Thanks to Lachlan Donald, there is now a Packer Builder for Anka. The Anka Packer builder is able to create macOS Anka VMs starting from a macOS installer app.

The builder builds a fully functional macOS VM from scratch, provisioned with Anka PV network and block drivers for near native build and test performance. You can configure CPU cores, RAM and Disk size. Quickly setup your Anka VM and then use ‘anka run’ to configure it with your dependencies.

Download it from GitHub. Packer Builder for macOS Anka VM

Refer to Anka documentation to create macOS Anka VMs from “*.dmg” or “*.iso”.

Anka Build Terminology – Components to setup on-premise iOS CI infrastructure

Anka Build is macOS native virtualization platform from Veertu. It’s a complete platform to implement and manage macOS VMs on a large scale for iOS CI. Anka Build includes lightweight Anka client, which is the native hypervisor to run macOS VMs on Mac hardware, the Controller, which is used to on-demand provision and manage macOS VMs and the Registry, which is used to store and distribute macOS VM templates for CI.

While Anka Build manages macOS VMs on a large scale for CI, all Anka Build modules by themselves are very lightweight, easy to deploy and manage.

iOS Ci with Anka Build

Anka Client

Anka client is a very lightweight mac application. Unlike, other server virtualization solutions for mac hardware, Anka Build doesn’t strip away the core macOS. Anka Build runs as another mac application on the mac hardware and enables the creation and running of macOS VMs. Anka Build macOS VMs are very responsive and perform at near native speed. These Anka VMs are used as on-demand build and test environments for iOS/macOS CI.

Anka Controller

Anka Controller module is packaged as a docker container. The Controller provides a single interface through its REST APIs to on-demand provision macOS VMs, requested by CI jobs. Think of it as central management for your Anka Build Cloud.

Anka Registry

Anka Registry module is used to store and distribute different versions of macOS VMs. Anka Registry is also packaged in a Docker container. A iOS/macOS CI job can request X quantity of N type of macOS VM. When Controller receives this request, it pulls N macOS VM (version tag) from the registry and spins up X quantity of these VMs using Anka Client on your Anka nodes. Anka Controller also maintains a queue of all incoming requests from the CI system and manages them.

Anka Node

Anka node is one or many Mac hardware on which you want to run your iOS CI jobs. You install Anka Build client on each of your Anka Build Nodes and then connect the nodes to the Anka Controller.

Connecting Anka Build to your CI system

While Anka Build platform consists of multiple modules, you only need to integrate your CI system to Anka Build Controller in order to start using Anka Build for executing iOS CI jobs. Anka Build Controller exposes REST APIs, through which you can integrate your existing CI system.

For Jenkins based CI implementation, there is a Jenkins plugin available, which can be used to very easily set up integration with Anka Build iOS cloud infrastructure.

Performance and Scalability in virtualized iOS build and test infrastructure

Growth is good, and when development teams grow, often, they find themselves having to choose between performance and scalability factors related to their development process. Most often, iOS application development project start by consuming hosted service offerings for their build and test processes. Then, as growth happens, team size increases, the velocity of code commits increase significantly, the number of projects increase, and soon performance issues like long queue wait times and longer build and test times start to creep up.

In most scenarios, one can throw more resources at this problem to address the issue. However, in the macOS world, that’s not the case. While scalable and high-performing platforms like AWS, Google Cloud, Azure which are powered by virtualization exist for Linux and Windows, nothing similar exists for macOS. All existing approaches to virtualization of macOS suffer from a tradeoff between scalability and performance.

Veertu Anka hypervisor eliminates the need for the user to make this tradeoff. Anka Build, powered by Anka hypervisor, enables growing iOS development teams to very easily, setup and configure a scalable and high performing AWS like private cloud for iOS build and test.

There is a lot of skepticism around the performance of iOS simulator test jobs on virtualized infrastructure, especially as the test portfolio expands. Anka Build addresses this for its users with a combination of three variables. – The performance of Anka VM, Time to provision an on-demand VM and VMs in Anka registry with pre-boot iOS simulator.

Anka VMs run on top of Anka Hypervisor, which is a new lightweight virtualization technology that leverages the macOS Hypervisor.framework to run macOS VMs in the most resource efficient manner. Instead of directly requesting and managing macOS resources like CPU or memory for the VMs, Anka Hypervisor, through the macOS Hypervisor.framework, lets the operating system manage the VM resource needs in the same way it runs other applications. As a result, Anka VMs perform much faster and are more responsive. Anka VMs are also packaged with a para-virtual block and network drivers, to enable faster execution of build and test jobs.

Time to provision or the time it takes to have an environment ready for the iOS build and test job is a significant factor that impacts overall performance. Anka Build addresses this with ‘Instant Start’ feature. ‘Instant Start’ offers on-demand provisioned instances instantaneously (1-2 sec) to execute the iOS Ci jobs.

iOS simulator UI test job performance on dedicated or virtualized hardware is impacted by, the long boot time of iOS Simulator. With Anka Build, DevOps can address this problem by pre-booting the simulator in the VM for each device type and pushing the VM to Anka registry. Then, CI UI test jobs, through Anka controller can on-demand provision instances from these VMs and use the pre-booted iOS simulator at full throttle. Each test is run in a clean, sterilized environment with pre-booted simulator of a particular device type.

In our internal tests, we have recorded that iOS simulator UI tests performed with Anka Build and pre-booted simulator VMs take less time than when running on dedicated hardware.

                                         

iOS simulator test in Anka VM



               

iOS simulator test on dedicated hardware