MacStadium customers use a variety of virtualization layers – a choice driven by a number of factors that you can read about here. One such virtualization provider is VMware's vSphere. Currently the most popular method of virtualization on MacStadium, vSphere is a long-standing giant in the field who has had time to develop a rich ecosystem with compatible tech. Perhaps not surprisingly, Jenkins – also the most popular alternative in his respective field at MacStadium – is among the techies.
As such, we have tried to discover best practices for this duo when paired with MacStadium hardware. We are not convinced that the best approaches to use in a Windows or Linux environment apply equally to macOS or iOS builds with Xcode. In fact, we often see customers put up with a good practice for the Windows and Linux worlds, only to later change policies for Apple-based builds.
For that purpose, MacStadium has begun to perform internal benchmarking of builds, and in the process we are developing sample code for what we believe is the best way to run VMs with Jenkins. We believe that volatile VMs will work best and that using the Instant Clone feature is the best way to produce volatile VMs on demand with vSphere.
Instant Clones has already had a good history of success. VMware has published quite a few articles on the subject, and all internal testing of MacStadium instantly confirms Instant Clones much faster than the old linked clones, making the volatile concept viable.
This VirtuallyGhetto.com article describes, quite accurately, the scripts needed to start with VMware vSphere as the only interface. To move towards Jenkins, a combination of additional scripts, configuration or packages will be required for feature parity. In future blogs and resource releases, this code will be available to the general community.
When it comes to early results, more World Cups seem to be the way to go. The first tests have yielded the following results:
Running two VMs results in a slower total real time per image, but much higher productivity. In this case, a net saving of about 8 minutes per building was achieved.
This 20% additional cost of running multiple buildings is confirmed by a MacStadium customer. In the customer's production environment, a VM build takes a very consistent 27 minutes. During the test without operating hours, this customer ran three VMs on the same node. All three completed with a build time of 32 minutes, or 10.7 minutes per building.
More to come!