Why you should use CI/CD for Unity games

Written by Markus Aksli

This article will go over the increasing necessity of continuous integration and deployment for Unity games. Before we cover the technical details, we will discuss how DevOps, in general, is undervalued in the video game industry, as is the rapidly growing value CI/CD can provide. Then we will discuss the specific benefits of CI/CD for Unity projects, the many technical challenges you need to consider, and the few solutions out there.

Here is an overview of the topics in this article:

• What is Unity?
• What is Codemagic?
• What problem are we solving?
• Why not just Unity Cloud Build?
• How Codemagic solves these problems

But before all of that, let’s start with some basics.

What is Unity?

Unity is a massively popular cross-platform 3D and 2D game engine. It includes an immense set of features, like powerful animation tools, a built-in terrain editor, sound mixing, and support for mobile, AR, VR, game consoles, and other devices. Unity is used by both hobby developers and huge AAA studios. It has been used to create popular games, like Escape from Tarkov, Pokémon Go, Monument Valley, Hollow Knight, Fall Guys, and many more.

Unity has a massive community of developers and an endless supply of official and user-created tutorials, guides, demos, and assets. There is no shortage of experts ready to help out any new developers and answer any questions on the Unity forums or Stack Overflow.

What is Codemagic?

Codemagic is a CI/CD platform that is mainly for mobile projects. CI/CD, or Continuous Integration and Continuous Delivery/Deployment, is a catch-all term for a set of principles and practices in software development. There are several dedicated tools and platforms to help implement CI/CD in practice, which usually involves automating the (frequent) testing, building, and delivery of the software. The tools integrate with the project repository to trigger this automated process when significant enough changes occur.

Codemagic CI/CD integrates with Azure DevOps, GitHub, GitLab, Bitbucket, and other self-hosted or cloud-based Git repositories. It supports native Android and iOS, Flutter, React Native, Cordova, Ionic, and, of course, Unity. You can automate the entire build, test, and release pipeline with codemagic.yaml, which integrates with your tech stack. Codemagic provides macOS and Linux hosts to build, sign, and deploy iOS and Android projects with ease. It integrates seamlessly with Google Play and the App Store.

What problem are we solving?

If you have never heard of CI/CD or DevOps before, you might be wondering what the connection is between these two and why you should even consider learning about it. As a game developer, you might find the idea of implementing high-minded software development practices just as off-putting as spending your valuable time marketing your game instead of just making a better game. This mentality isn’t uncommon.

A culture of working hard and not smart

The video game industry is notorious for its pervasive culture of crunch and problematic development cycles. This has become a painfully visible issue with the increasing prevalence of disappointing, buggy game launches. This might even seem somewhat predictable.

Making games is complicated. It’s a collaborative effort that involves a headache-inducing number of creative disciplines interfacing with seriously complex software. As consumer demands, budgets, and project sizes increase, is it any wonder that the number of human errors is increasing with them? Another rising trend in the industry points us to a likely culprit – mismanagement.

The trend I am referring to is the increasing number of developer horror stories: overeager release dates leading to countless delays, key team members leaving projects in the middle of absurdly long development cycles, programmers working 80-hour weeks to drop a massive day-one patch after launch, and more. These have become scarily common occurrences. It really shouldn’t come as a surprise that properly implemented DevOps principles are a rare sight outside of the industry leaders. But this is certainly not the way things should be. Anyone who has worked elsewhere in the software industry will tell you this.

No matter how talented and passionate the developers are, games are hard to make, and human error is unavoidable. But this is precisely why frequently validating the quality of the game with a consistent build and release process is vital for games, both before and after release.

The possible benefits of CI/CD for Unity projects

This post won’t go off the deep end into the critical value of DevOps in modern game development. (This GDC talk can give you a basic intro.) At the very least, CI/CD has started playing an increasingly important role. CI/CD isn’t a magic bullet that will make every release go without a hitch, but it ensures that the project builds successfully, passes tests, and deploys to the distribution platforms. This helps create a solid foundation for more frequent QA testing and, ultimately, more confidence in the release process and final product. With all this in mind, we can finally start talking about how these benefits manifest in a Unity project.

Aside from the obvious observation that manually building a Unity project wastes time (potentially a lot of time, depending on the size of the project), it also is far from a frictionless experience. Suppose your project is intended for more than one platform. In that case, you might have already experienced the pain of switching platforms, waiting, running a build, waiting, zipping or distributing the build, waiting, and then repeating the same monotonous cycle in the Unity Editor to build all of your desired targets. Considering the context of what we just went through, there is clearly a better alternative.

Specifically, the command-line arguments for the Unity Editor make it possible to automate the build process and run tests (writing them is a whole other unappreciated topic) without ever needing to open up the Unity Editor GUI. As a result, it is possible to script Unity builds to execute them more efficiently with less waiting around. You can then hook up these scripts to cloud-based CI/CD platforms or your local dedicated machine through Jenkins. This comes with a lot of enticing promises:

Forget about switching platforms

If you choose to set up automation for your build process, you can finally say goodbye to this sight.

Building, packaging, and distributing automatically

You no longer have to waste your valuable development time manually building, zipping, and distributing to your target platforms. You can automate all of these steps through scripts in the build pipeline. As promised earlier, this leaves you with more time to spend on useful tasks that add value to your game.

A consistent build pipeline and healthy codebase

One of the Unity Editor’s great features is that it allows you to develop your game from pretty much start to finish without ever needing to build the player. But if you manually and infrequently run builds on a dedicated machine, you may discover that you run into errors or distribution issues at the worst possible time.

As mentioned before, CI/CD can run tests, build, and distribute to your target platforms or QA testers automatically and, therefore, more frequently. This can be triggered with commits, tag creation, pull request updates, etc. Switching to an automated and more frequent process allows you to constantly monitor the health of your source code, build pipeline, and distribution integration, as well as to be confident in your readiness to distribute your initial release and any patches that follow.

Build for iOS or macOS

If you have access to macOS hosts, you can finally use your preferred OS to develop your game without having to worry about being able to build, sign, and distribute on Apple products. You can also use these hosts to build for macOS with the ILCPP backend, which is only possible on macOS hosts.

The technical challenges of Unity CI/CD

All of that sounds amazing, and it can be. However, you will face many unique challenges when trying to set up any kind of CI/CD solution for Unity, one of which was already mentioned.

Unity is a cross-platform game engine. This does lead to the inevitable problem of building for Mac or iOS. On Windows or Linux, you can build the Xcode project for the player, but it still needs code signing credentials and to be uploaded to a macOS host to generate the final archive for distribution. This means macOS build hosts are necessary at some point in the pipeline for these targets. Though macOS hosts are provided on some managed CI platforms, the problems don’t stop here.

The Unity SDK and projects also introduce greater bandwidth demands than what is usually necessary. A basic project and the Unity SDK alone will already require a considerably larger VM image than a comparable native mobile app setup. The storage requirements can grow astronomically with large numbers of 2D and 3D assets, audio files, etc. This means VMs need more storage space and are more sensitive to the availability of permanent storage. The problem of hardware compounds with the many GPU-bounded or accelerated jobs in a typical Unity CI/CD pipeline. This includes running Play mode unit tests, integration tests, baking lightmaps, building shader variants, etc. But as it turns out, we need to solve an even more significant problem first.

The Unity license system

The technical complications in establishing a CI/CD pipeline are mostly sidelined by the Unity license, which has long been the primary stumbling block in this undertaking. The Unity Editor requires a registered license, which means signing in with a Unity ID email and password or providing a license file. This also applies when you use the Editor to build a project without the GUI interface on an arbitrary cloud VM on your chosen CI/CD platform. The Unity Editor license has two key restrictions, which turn this from a mild annoyance into a major issue:

1. You can only use it on a maximum of two machines
2. The license holder can only use one Unity Editor instance at once

This makes it very unsuitable for managed CI services like GitHub Actions, as it requires you to activate and deactivate a license for each build. You cannot scale with a single license since it cannot be used for multiple builds at once. (This can lead to license infringement since a license is meant for one person.) This would also clearly cause issues with features like autoscale in Azure.

You can use the license for a local dedicated build machine or try to release it automatically after building. Still, you can quickly run into flexibility problems when your team size or concurrency demands increase. These restrictions have already made cost optimization through license management a persistent issue for development teams, but they quickly become a prohibitive hurdle for CI/CD systems.

Unity Build Server

To counter these restrictions, Unity launched a long-awaited updated licensing scheme in 2020. With Unity Build Server licensing, you can leverage leasing, returning, and automatically collecting non-renewed licenses through a dedicated license server. This also comes with a much cheaper pricing scheme for licenses.

Unity Build Server licenses, however, come with their own set of significant restrictions:

1. You need a dedicated license server. a. It can run on common Linux or Windows OS versions but needs a consistent hostname, MAC address, and number of CPUs to function. (Cloud VMs beware.) b. This server is intended for private networks only but can be exposed through SSH tunnels.
2. Only available for Unity 2019.4.3 LTS and later.
3. CLI only (no GUI Unity Editor).
4. Available for Unity Pro or Enterprise license plan.
5. You can purchase new licenses in increments of one Unity Pro Build Server license ($600 per license) or five Unity Enterprise Build Server licenses ($400 per license).

So the new system is a floating license server running on Windows or Linux that can be exposed to clients and managed CI services in a remote network through SSH tunnels. The server allows licenses to be used and scaled with ease and for a lot cheaper. This is absolutely the recommended licensing scheme for cloud-based CI/CD pipelines, even for small teams. Still, it does require a decent amount of setup and customization to get working.

Why not just use Unity Cloud Build?

So, there are some serious challenges with using the Unity Editor license before setting up CI/CD. However, a certain option has remained conspicuously absent from our list of possible ways to get CI/CD running in Unity projects. An easy way to sidestep the license headache would be to use Unity Cloud Build instead of any common but general-purpose CI/CD tools and platforms.

What’s the problem?

Unity Cloud Build is a beginner-friendly CI/CD solution provided as a paid service by Unity itself. This means minimal setup, but more importantly, it completely sidesteps the licensing problem. Unity Cloud Build requires you to pay a monthly fee for all team members and extra for more concurrent builds without needing to buy more licenses. It might sound like an appealing and headache-free solution to the mountain of problems mentioned earlier, but the devil is in the details. With Unity Cloud Build, you are forced to trade performance and features for easy setup.

Can’t automate distribution

The biggest issue is that you can’t really automate distribution through Unity services. Unity only provides the Unity Distribution Portal (UDP), which is only connected to third-party stores, like Samsung Galaxy Store and ONE store. This leaves you with no clear way to automate distribution to Google Play, the App Store, Steam, itch.io, etc. This means Unity Cloud Build is less of a CI/CD solution and more of a managed CI service that allows you to download builds manually.

Slow builds and lack of control

There is very little control over the build environment. You have no control over the VM specs and external tools. Another obvious omission here, considering what was discussed earlier, is the ability to provide custom VM base images or to use dedicated hosts. This ends up making Unity Cloud Build quite slow and leaves you with no options to speed it up.

Hard-to-diagnose issues

Because Unity Cloud Build is a managed system with very little control, you can easily run into build issues that are particularly difficult to diagnose. Because you can’t have direct access to the build machine or VM instances, you are left having to rely on the forums for support. Some solo Unity users have opted for manual builds for this exact reason.

How Codemagic solves these problems

We’ve gone over the problem, why you should solve it, and the issues you will face in doing so. On the surface, Unity Cloud Build seems to circumvent all of this, but it comes with its own set of headaches. So, now we finally get to what Codemagic offers as an alternative.

Control

With Codemagic, you have complete control over your CI/CD pipeline. This can add value for teams of any size. For hobbyists, it can mean easily integrating with external tools like butler to automate itch.io releases. For enterprise customers, it can mean providing custom base images on dedicated machines.

Hardware options

Codemagic can provide macOS and Linux VMs with varying levels of performance to suit your needs. They offer dedicated macOS hosts, which can be especially critical for speeding up Unity builds. This way, the build machine only needs the latest diff of your project and can include a pre-installed Unity Editor, the latest Xcode, Android SDK, etc. And you get to choose the build machines, including the powerful Mac Pros, as well as Linux and Windows machines, depending on your target platform. Of course, for different workflows you can use different machines, but you still get to build all the versions with just one trigger.

Distribution

Codemagic is a dedicated mobile CI/CD with easy integration to distribute to the App Store or Google Play. There is no need to write complicated Groovy scripts or to worry about credential privacy. Codemagic has built-in tools to encrypt your credentials and even to automatically sign your iOS builds. Codemagic offers macOS hosts with Xcode and a robust, secure system to set up your credentials for signing and distribution. You can easily implement distribution to other platforms with post-build scripts.

Flexible pricing

Codemagic offers an unlimited Free plan for hobbyists. You can upgrade to more build minutes and choose what level of hardware you want, but you only have to pay for what you use on the Pay as you go plan. Professional and Enterprise customers have access to even more features that are entirely absent from Unity Cloud Build. You can optimize your costs by paying for exactly what you need with all of these options.

Support

You don’t have to dive into setting up Codemagic for Unity by yourself – you can first contact Kevin to get a demo. You can choose to use your Unity Editor license, or Codemagic can help you get set up with the Build Server license.

Once you are up and running, you can rest assured that Codemagic has a passionate and reliable human support team ready to support you. Codemagic was voted the best CI/CD tool in Flutter’s user survey for a reason. You can contact Codemagic whenever you run into issues with any part of your pipeline and get a quick response.

Codemagic vs Unity Cloud Build: Quick comparison

• Speed: Codemagic offers faster build machines than Unity Cloud Build.
• Price: Codemagic has a free tier, which Unity Cloud Build does not. Per-minute prices for macOS build machines are lower for Codemagic than for Unity Cloud Build. Codemagic also has a tier with fixed costs and unlimited usage.
• Ease of use: Unity Cloud Build could be easier to set up, but builds are harder to debug. Once you’ve set up a YAML configuration for one Unity project with Codemagic, it is very easy to use it for other projects, and it takes less time and effort than with Unity Cloud Build.
• Publishing: Codemagic offers publishing options to App Store, Google Play, Oculus Store, Steam, etc. Unity Cloud build doesn’t allow you to automate deployment of your Unity apps.
• Source control options: Codemagic works only with Git repositories. Unity Cloud Build works with Git, SVN, Perforce, PlasticSCM, and Mercurial.
• Integrations: You can find the list of integrations for Unity Cloud Build here. The list for Codemagic integrations can be found here, and it is much more extensive.

Conclusion

The necessity of CI/CD in game development is becoming increasingly apparent. It’s no longer reasonable to try booting up your one dedicated build machine after months of inactivity to release your game to all your different target platforms. As working from home has become more and more common, it has become more and more important in production to have a clear and reliable path to build and distribute your Unity project.

There are many challenges with implementing a CI/CD solution for Unity development. The performance and bandwidth requirements are unusual, the licensing system can work against you, and the Unity service solution leaves a lot to be desired. Codemagic offers a powerful solution to these issues, with some unique advantages.

No matter which solution you choose, hopefully, you now have a better idea of why CI/CD is vital in game development and what your options are for Unity games.