ilquest

I’m a huge fan of continuous integration. So I was pretty disappointed when Apple removed the 4-core options for the 2014 model of the Mac mini.

That’s why we bought a used 2008 Mac Pro with 2 4-core Xeon CPUs (Model identifier 3,1) to replace our 2010 Mac Mini, which just couldn’t keep up with the number of of build jobs we were throwing at it.

According to Geekbench the 2008 Mac Pro offers roughly the same multi-core performance as a 2012 4-core Mac mini (Both offer about twice the performance of the top-notch 2014 MacMini).

However, the Mac Pro offers room for 4 internal drives, PCI expansion cards and supports more RAM, that’s why we decided against buying the 2012 Mac Mini, even though our local reseller still has some in stock.

The Mac Pro’s major disadvantage is it’s lack of a SATA 6G interface. It’s older SATA 3G interface offers a theoretic peek throughput of 300MB/s, while modern SSD drives easily reach 500MB/s or more. We thought we could work around this bottleneck by buying an SATA 6G PCI card, but that process didn’t work as smoothly as we thought.

We ordered an Sonett Tempo SSD PCI card, which lets you mount a single SSD directly onto the PCI card itself. This way we wouldn’t need an extra adapter or cables to mount an 2.5″ SSD in the MacPro’s 3.5″ drive bays.

Shortly after having placed the order, I run into this little detail on Sonnet’s product page:

Tempo SSD Pro is recommended for Mac Pro 1,1 2,1 and 3,1 instead of Tempo SSD. These early Mac Pros have PCIe 1.1 slots which will negotiate the two-lane Tempo SSD card down to one lane. These early Mac Pros will correctly negotiate with the four-lane Tempo SSD Pro.

That didn’t sound too promising, but luckily I was able to change our order to a Sonett Tempo SSD Pro Plus – which is twice the price, but also offers room for two SSD drives on the PCI card.

Once the card arrived, we installed it – only to discover that while we could install OS X Yosemite on an SSD attached to it, our Mac PRO refused to boot from that drive. According to the Sonnet support page, our card already comes with the most current firmware. Since the card is advertised as bootable on OS X, we were a little confused.

After a while of digging around, we found a Sonnet blog post from 2013 announcing boot support for their Tempo SSD and Tempo SSD Pro cards, which led us to a firmware update, that was not offered on the Tempo SSD Pro Plus downloads page.

We decided to give that firmware update a shot, and the updater offered our PCI card as a target. It told us the actual firmware update process would be performed during next restart, but much to our dismay, nothing happened during reboot. We were still stuck with a non-bootable SSD drive.

Since the firmware update was created before Yosemite was released, we weren’t sure it was fully compatible. Also, the Mac Pro was booting of an FileVault encrypted hard drive, which could interfere with whatever process the Sonnet updater uses to flash the PCI card.

We booted the Mac Pro from an external, unencrypted drive with OS X Yosemite, run the updater application again, and this time the Mac Pro started into an EFI prompt, asking us if we wanted to update the card’s firmware. After that procedure had finished, we were finally able to boot from the SSD drive attached to the Sonnet card.

Disk throughput went from around 60 MB/s with the internal 1TB hard drive to around 450 MB/s with an Samsung 840 SSD attached to the Sonnet card. That’s still not as fast as 1TB/s a current Mac Pro or Mac Book Pro achieves, but a pretty solid number compared to the money (~1000 €) we invested in this whole project. My only wish is that getting this setup to work wouldn’t have been that time consuming.

My company purchased a around a dozen of different Mac Minis since its introduction in 2005. Some of these machines were used for standard server issues, like serving web pages or database entries. But many of these Mac Minis have been used for continuous integration.

With continuous integration there’s a dedicated server monitoring the code repository a group of developers uses to store the code for their software projects.

Whenever a change is checked into this repository, this continuous integration server tries to compile the changed source (if the source code is written in a programming language which needs to be compiled into machine code) and executes tests to confirm that the code does what it is intended to do.
Should any of these tasks fails, the developer that made the breaking change gets notified and is hopefully able to fix the problem, before co-workers are on his or her throat.

Common software tools, that are used for continuous integration are Hudson or Apple’s own Xcode Server.
There are even hosted continuous integration services like Travis, but depending on the project you are working with, these services are not always an option, e.g. because of a client’s security policy.

Continuous integration is especially handy, when you are working with code modules that are shared between different projects.

When a developer makes a change to such a module, for instance to add a new feature into application A, he is usually not aware that application B also depends on that code module (at least that’s the case with me).
With continuous integration setup right, the change will trigger builds and tests for all software projects that depend on the affected module.

Hence, a change that only effects a single line of code my trigger a dozens of build and test jobs. Speed matters here, because you wan’t all projects that are affected by late-afternoon code checked before the developer goes home.

Also, if a developer has been fixing a specific bug, he wants the fixed version of the software project in the hands of his testers as fast as possible, so these people can check if the bug has indeed been fixed. Usually, test builds are distributed by the continuous integration machines, too.

Up to this date we use an aging Mac Mini Mid-2010 for continuous integration, but the machine has become painfully slow compared to a current Mac (Book) Pro most of the developers in my company use.

We always considered the purchase of an Xserve (while it was still around) or Mac Pro as overkill, because we neither needed a lot of graphics power, internal storage capacity, nor redundant power supplies for continuous integration. Also, these machines usually sold at around 3 to 4 times to price of a maxed-out Mac Mini. All that mattered was somewhat decent compile times, which depend on the clock speed of the CPU and the number of its cores.

We wanted to buy a new machine in 2013, but no new Mac Mini model was released that year. So we were hoping for a 2014 model, which was finally released last week. Unfortunately this iteration is very disappointing:

Much to our dismay Apple removed the 4-core option it’s predecessor offered, which results in approximately half the compile speed of the former top-of-the-line Mac mini (Geek bench multi-core score 11319[2012] vs. 63518[2014], Source PrimateLabs).

This strategy is confusing to me: One the one hand, Apple supports continuous integration with Xcode Server (which was released last year), on the other hand it takes away the only attractive Mac to deploy it own.

Most likely Apple’s hardware department doesn’t see a market, where Apple’s developer tools department does.

The 2014 Mac mini is clearly not made for continuous integration, so we see ourselves forced to shop for a used Mac Pro (pre-2013).