After having a closer look, we found out that macOS can’t be put in a container, while in Docker-OSX macOS is actually virtualized on Linux, and to launch a container you need Linux or Windows. On Github you can find Docker-OSX, quite an interesting solution because containers require much less resources and launch much faster, as well as can transmit data between each other. You can close it or hibernate it after each task. So we can create 3 virtual machines with 2 CPU cores and 5 GB RAM, if there’s enough space on the SSD.īut you can also change CPU and RAM amount before the launch as you don’t need to have a virtual machine constantly working. If there’s 3 of them, execution time of each increases from 3 to 5 minutes. On our Mac, 2 project building tasks can work simultaneously just fine. But note that if there won’t be enough dedicated resources, a job will take more time. When it comes to computer performance, each instance can be given a certain amount of resources. But if we consider dependencies, the project itself, and Xcode cache files, then it’s better to leave 75 GB for one virtual machine. That’s why you need a powerful device.Įach virtual machine is a machine with a full system and Xcode, which in total requires 50 GB. Virtualization is one of the most resource-intensive processes when deployed on your devices – virtual machines need a good amount of resources to operate. Using it together with Vagrant, you can write a rather convenient script, which will allow you to create a virtual machine with all necessary dependencies and execute tasks on it. Gitlab Runner offers Parallels and VirtualBox as an executor. The first way to separate our runners from the external ones is virtualization. When scaling CI/CD, the trouble is that you should install/update all necessary dependencies on every machine and monitor that no one breaks anything. Or while deployment will be ongoing, you won’t be able to operate anything because of the installed dependencies.Īlso, you can’t just launch several tasks on one runner without preparation and a couple lines of code. If anyone decides to deploy CI for another project, they can easily use any new dependency to crash your whole CI/CD. Quite easy, isn’t it? There’s a big downside, though. It takes 3 minutes to build the project, and it takes 9 more minutes to build it and upload to App Store Connect. We use Mac Mini 2018, 6-core Intel Core i7, 16 GB RAM. After that, you can register runners and launch a pipeline. When launching a build, we use Python scripts to input build info into the repository, and we also change the task status in the task tracker. Also, on the local machine you can install any necessary dependencies, which is important for us. The only thing you need to do is install Xcode Command Line Tools, rbenv, Fastlane, and Gitlab Runner. It’s a convenient, but not very reliable way. You can buy and place a Mac Mini in the office. To estimate time for the completion of the tasks, let’s take a project that has been developed for almost 2 years and has 20 Cocoapods dependencies, including Rx, Realm, Firebase, Swinject and others. We researched possible deployment options and compared how easy and how long it takes to configure, use and scale: In this article, we’ll look at all possible solutions we found for the deployment of Gitlab CI/CD on a device and in the cloud. First we thought of Docker, but there was neither enough info about it nor any other possible ways. After our IOS department deployed our CI/CD on a Mac Mini, we got an idea of scaling and encapsulating it. Hey, Habr! I’m Yaroslav Fomenko, Doubletapp iOS-developer.
0 Comments
Leave a Reply. |