ilquest

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).