I’m seriously in love with Unity Cloud Build. It’s enabled me, as a solo developer, to focus on other aspects of development and business. Anyone using Unity for Android/iOS/Web Player should examine whether it would be an asset to their development pipeline.
At each of my previous employers (even the small ones), we used build servers to do continuous integration and build mastering of our console games. While it was sometimes a fragile process, it paid off in spades. Our on-site build servers handled merging all the work together and cranked out fresh playable builds for QA or for delivery to our publishers. The only cost was setting up one or more build machines and the occasional programmer/IT time to add new hardware, update software/libraries, or add new target platforms.
Given that it’s very comfortable to work in that kind of environment, it’s one thing that I wanted to have even in my solo development. Thus it became the first thing I set out to implement when I ventured into independent development last year. It ended up being a bit more time-consuming than I imagined it would be at first.
The Hard Way, Part 1: Creating A Custom Solution
I definitely wanted to target Apple devices, so this meant that those builds had to be authored on a Mac machine. So I started off by firing up my Mac Mini and installing my CI build service of choice: Jenkins!
Jenkins is definitely worth checking out; they take care of much of the hassle and leave minimal work for the developer. Everything can be accessed via their web client: monitoring and triggering builds, tagging and archiving, sending notifications on success/failure, along with a host of other features.
A Google search for “Unity Jenkins” pointed me to a great tutorial that I started to follow. As it turned out, there was already a Unity Jenkins Plugin. It appeared to automate most of what I would need. I was ecstatic! In 20 minutes, I felt like I already had the tools to get continuous integration rolling for my games. Soon I had the build server pulling down all of the game content from an SVN repository and was well on my way, or so I thought.
The Hard Way, Part 2: Results of Custom Solution
Fast-forward to the next day (after a late night of frustrated attempts), and the situation was not quite so joyous.
No amount of arguing, bullying, or pleading would get the entire process to work correctly. I had followed all the steps from setting up provisioning profiles to configuring Xcode to creating a build slave that ran on the same machine…nothing worked perfectly. Granted, it worked beautifully for all builds that were not targeted at the Apple platforms. It should also be noted that Jenkins performed admirably and made it so I could customize things every step of the way. The biggest problem was Apple’s arcane and annoying development process.
Another long day of debugging and testing and I finally had the process working from beginning to end. Builds for iOS and the Mac App Store were finally created and signed correctly and were properly uploaded to TestFlight to be pushed out to my devices. The whole thing was elegant in no way, and very closely resembled a Rube Goldberg machine. But it worked. God help me, it finally worked.
For the next few months, this cobbled-together CI system ran beautifully with very little maintenance required on my part. Despite being a little unhappy with it, it was a passable solution, and I resolved myself to revisit it in the future.
The Hard Way, Part 3: Disaster Strikes
One day, I got a notification that I had an OS update available on my Mac and I applied it, thinking it would be no big deal. This update wrecked everything. Nothing worked at all. The server installation was ruined, the slave wouldn’t connect, the signing was broken, Xcode was pitching a fit…but that wasn’t the worst. The worst thing was that I had not backed up my system before applying this update. I had no easy way to recover.
In all my years of programming, I’ve never been so upset that I cried over something breaking. This time was the closest; I was distraught.
As I was sitting in my chair stewing and contemplating my options, I get a notification from my e-mail client: “You are invited to try Unity Cloud Build Beta!”
I began to wonder if someone from Unity was spying on me. The timing was almost too fortuitous. Pushing aside my crazy paranoid thoughts about Unity, I decided to give it a shot. What could it hurt to try it at least?
The Easy Way, Part 1: The Clouds Part
I followed the link and did the basic setup, which went quickly. Twenty minutes later, my game was building in the cloud. I kid you not, it was that easy. I was playing a WebPlayer version of my game built on their servers just a few minutes after completing the setup. It monitored my SVN repository, sent e-mail notifications, and supported a few platforms (most importantly, iOS.)
For iOS, which had been the thorn in my side, I just had to get a couple of items for signing apps off of my Mac. They turned a process I had struggled with for three days into a simple 5 minute task. It worked right out of the gate. 10 minutes later, I was playing my game on my phone with no hiccups.
I almost cried tears of joy. Seriously. I could simply bring up the Unity Cloud Build project in Safari on my iPhone or iPad and install from there. No TestFlight required. No yelling at my machine, no begging the ghost of Steve Jobs to take pity on me.
As an added bonus, I got back one of my Unity Pro keys since it was no longer needed on my Mac Mini. I re-purposed that key and put it on my laptop. I could now safely ignore Apple machines and the bizarre provisioning requirements entirely (sorry, Apple guys, my personal preference is PC.)
Another great bonus I discovered was that I could choose which Unity installation to use for each project in my list. No need to upgrade Unity on my build machine anymore, because the Unity Cloud Build team handles all of that stuff. I can simply tell it to use the version of Unity I have installed on my development machines, or always ask it to use the most recent published version of Unity.
The Easy Way, Part 2: The Angels sing
Since that day, I’ve exclusively been using Unity Cloud Build, and while it’s been great, it’s not quite perfect. If I could squeeze just a couple more features out of it, I don’t think I’d need to even consider a custom solution for my Unity projects. Here’s my short wishlist:
- Support for building on more platforms. Ideally, it would support all of the platforms that Unity supports, especially Windows/Linux PC builds.
- Mercurial support. It’s the one major source control system they don’t support yet.
- Options to select Unity installation on a per-platform basis.
Even without those things, Unity Cloud Build will remain my go-to solution for authoring iOS/Android/Web Player builds, and I strongly recommend anyone making a Unity game for those platforms to check it out ASAP.