![]() ![]() ![]() Scaling this infrastructure is as simple as adding new machines to the cluster of hosts, with the Anka CLI and the Buildkite agent running on them. Since each machine only needs to run the BuildKite agent and the Anka command line interface, machines can be in different locations to make our setup more resilient to outages. With this setup, we can run multiple pipeline steps simultaneously in separate virtual machines across several host machines. Delete the cloned virtual machine when pipelines succeed, fail, or get canceled.Run the pipeline step inside the virtual machine.Mount the checked out source code from the host into the virtual machine.Boot the virtual machine almost instantly, thanks to Anka's virtualization technology.Create a clone of the specific virtual machine image.The plugin will automatically do the following: With Buildkite’s excellent support for plugins, we can simply set a step in our build pipelines to run using this plugin. To do this, we used Chef’s Buildkite plugin for Anka. ![]() With our virtual machine images ready and the Buildkite agent running on a cluster of local Mac minis, the next step was to figure out how to provision a virtual machine for each build, and run the pipeline inside it. All build agents can pull images from this registry and clone them to run build pipelines. Once the virtual machine is created, it’s added to Anka’s Registry, which acts as a central repository of versioned virtual machine images. Also, since the whole process is based on configuration files, it can be source-controlled and versioned. The first layer only installs Ruby, Homebrew, and a few other basics, while the layer on top of it installs Xcode, making it much easier and faster to create a new image that has a new version of Xcode, based on the first layer. The images are built as separate layers on top of each other. Using Packer, we can create an image that has Xcode, fastlane, CocoaPods, and all the other essential tools for our build jobs while only taking the macOS installer downloaded from the App Store as input. Packer lets us automate the virtual machine creation process out of a bunch of confirmation files. To make that process easier, we used HashiCorp’s Packer. The first step we needed to do was to create an Anka virtual machine that we can clone for each build. Buildkite offers a simple, modern UI with the ability to easily create sophisticated pipelines. We decided to stay away from Jenkins since it’s too fiddly to set up and go for something more modern.Īfter trying different tools, Buildkite seemed to best fit our needs. The next challenge we faced was picking a frontend to schedule and manage our builds. Anka is a virtualization technology for macOS build on top of amework that offers a container-like interface and offers a simple command line interface to spin up and manage virtual machines. Unfortunately, Docker doesn’t support macOS containers, so we decided to use Veertu’s Anka. To help reduce flakiness and the eventual configuration/environmental drift, we decided from the get-go that builds need to run in an isolated environment, like Docker containers, rather than running them directly on the host machine. This tool does nightly runs that take many hours to complete, and while running it on CircleCI is possible, it wouldn't be cost effective. In addition to that, we have an internal tool we have developed to do a combination of functional and stress testing on the SDK. This is currently not possible on CircleCI, and while there are many services that let you do this, we preferred to utilize the extensive set of testing devices we already had at our office. This would help us find obscure UI and performance issues. While CircleCI works great for us, we wanted to run our UI tests on physical devices instead of just simulators. Challenges with our current infrastructure In this post, I’ll walk you through what motivated us to do it and the tools we used. As a result, we decided to set up our own CI infrastructure. While we’re big fans of CircleCI and use it for continuous integration for both our iOS and Android SDKs, but as our team grows, our needs have changed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |