Is Unity a platform facilitating Continuous Integration and Continuous Development? How do developers handle the practices of automating software building?
Unity, a versatile cross-platform development environment, consists of a powerful graphics engine and an editor providing all features necessary to create real-time digital experiences. The tool enables efficient multi-platform development, easy and fast prototyping, and the thriving community behind it supports creators. For more information about the Unity engine, check out the article giving a bigger picture. The engine, which most remarkably facilitates game development, can be employed with equal success in industrial and business AR/VR applications.
Continuous Integration/Continuous Development
Continuous Integration (CI) is an approach in software development, involving immediate testing and reporting of frequent, stand-alone changes. The approach is aimed at early detection of possible malfunctions and allowing rapid response, improving the process flow.
Continuous Development (CD) is an umbrella term, covering topics such as CI, continuous testing, continuous delivery, and continuous deployment.
The CI/CD pipeline is a set of actions performed to deliver a digital product or its new version. The process requires easy access to single shared repositories, where the code can be integrated continuously. It’s used to automate the software development process, facilitating code creation and testing (that’s the CI part), and in the end – a secure deployment of the brand new version of the product (CD).
CI/CD is important to quality software development as it helps accelerate the process and eliminate errors and defects, delivering a better product faster. Intuitively, the CI/CD, as a widely adopted set of practices aimed at improving the software creation process, should be commonly enabled without obstacles. Theoretically, it is, but the reality is a bit harsh.
The benefits of Unity
Projects built with the engine are compatible with various platforms, devices, and operating systems. The compliance doesn’t occur automatically but stems from skillful development and implementation. Older app releases often can’t be seamlessly transferred into, for example, iOS, as their builds are based on too many solutions depending on the Android system (or any other platform, being their “home port”, for which they were primarily developed). Meticulous choice of libraries dedicated to certain platforms, or – to an extent – accepting the limitations of the engine is an inseparable part of Unity developers’ life. Otherwise, a significant amount of work would perform solely with one system.
The engine shows a give or take attitude, where every process has its price and requires other actions. Developers can create multi-platform applications but need to avoid solutions not supported on every platform, limit native plugins, or at least ensure such plugins or substitute features are available on each supported platform. That’s the side-effect of maintaining several projects in various technologies on each necessary platform.
Jack of all trades, master of some
Unity’s ability to facilitate applications working in nearly all environments is huge work- and time-saver. Thanks to the engine, companies do not need to hire developer teams for every operating system. Nevertheless, the familiarity of other platforms’ functioning comes in handy – Unity developers don’t need to be experts in Android, iOS, UWP development, but should know the platforms and, most preferably, be able to write simple code in their native technologies.
Unity enables the relatively easy creation of outstanding 3D experiences without specialized programming skills due to its built-in tools and functionalities. Its emergence was a revolution in game dev, arming creators with a life-changing tool and allowing them to build a plenitude of projects, also in the indie field. Used for years primarily in game development, the engine caught the interest of AR/VR developers, who appreciate its potential in serving 3D models in spatial projects. For more benefits and features of Unity see the overview.
The challenges of the CI/CD pipeline in Unity
Unity is a well-seasoned, already established solution (released originally in 2005), but the dynamically growing demand causes growing pains. While the engine has many advantages, it still has some flaws, and the difficulty of establishing an efficient CI/CD pipeline is one of the major troubles.
While Unity is cross-platform and nearly universal, the nearly part is a challenge. Working well with applications developed for Android, iOS, and Linux, the engine lacks convenient free customizable CI/CD solutions, and even the paid official Unity solution still has some limitations and won’t support all platforms.
The engine is problematic in the scope of the version control (Git, GitLab, etc). With the latest version, the engine creators started releasing working solutions, until then, Git service providers offered facilitations on their side. On Unity’s side, versioning required specific preparation before submitting work to the repository.
Solutions
1. Unity Cloud Build
Released in 2015, the Unity Cloud Build brought change to the build process, enabling continuous integration services for Unity projects. It’s easy to set up, user-friendly, and allows avoiding licensing issues, but not free anymore. However, UCB is not Unity’s wunderkind, as using it is associated with performance loss and limited access to features. Currently, the supported platforms include applications developed for iOS, macOS, Android, WebGL, Windows Desktop, and Linux.
The UCB streamlined CI/CD execution in Unity, reducing the need for unnecessary workarounds. The solution monitors source control repositories, automatically updating detected changes. Automation with UCB covers code compilation, deployment, and testing, enabling rapid iterations of developed projects.
Automation services covered by UCB result in
- faster distribution, thanks to the cloud-based build compiling infrastructure, executed in parallel for multiplatform works. The builds are downloadable for all team members without restriction
- shorter time-to-market achieved through reduction of manual work and intervention, and, of course, the necessity of only one build process for projects meant for various platforms
- improved quality, since the process detects changes continuously, spotting potential errors at the same time as they are compiled into the build
| Pros | Cons |
| Easy configuration | Lack of support to some platforms |
| Official Unity support | Paid |
| Still evolving | Low performance |
| Low flexibility | |
| Lack of integration with: Google Play, App Store, etc. |
2. Cloud Services / Cloud platforms (Azure, AWS, etc.)
Cloud platforms are highly versatile tools for performing cloud computing and data processing without utilizing the user’s computing power. Thanks to their flexibility, it is possible to install a selected system, dependencies, and tools, including Unity. An environment prepared in the cloud can serve as a platform for CI/CD, which, due to the characteristics of cloud solutions, will be flexible and scalable, enabling continuous and stable access to services. Unfortunately, it is probably the most expensive solution, not only because of the sole pricing of cloud services. The size of cloud platforms and the vastness of the possibilities means that creating the environment requires highly skilled DevOps followed by expertise in Unity and its specific requirements. These skills also come at a cost. Cost optimization of cloud solutions is a broad topic, deserving a separate article.
| Pros | Cons |
| Flexibility | High costs |
| Good performance | Considerable effort and knowledge required for configuration |
| Scalability | Potential problems with the configuration of some platforms |
| Availability/stability |
3. Game CI
A free solution based on Ubuntu docker image with Unity client installed. Thanks to the tutorials prepared by the developers, integration with the Git version control system and CI/CD execution is extraordinarily easy. The extensive documentation leaves few questions, reducing the tech threshold. Unfortunately, this solution requires a separate physical or virtual machine, since none is integral to it. While developers can use GitLab or GitHub servers, their capabilities are limited, especially in the free version. Still, already having access to a computing platform, developers can easily configure a docker image on it and integrate Game CI into their version control system with relatively little effort. However, utilizing Ubuntu means that not all Unity features are available (including the lack of il2cpp, responsible for improving applications’ support), therefore it becomes problematic or nearly impossible to prepare CI/CD for UWP and macOS and iOS platforms using il2cpp scripting backend.
| Pros | Cons |
| Relatively easy configuration | Lack of support of some platforms |
| Dockerization enables building on GitHub/GitLab servers, but… | …increasing performance still requires an own virtual/local machine |
| Free solution, but… | …the amount of free minutes available in GitHub Actions/GitLab CI is limited |
| Documentation with examples |
4. Automation servers
A type of CI/CD-dedicated servers, designed to make building, testing, and deploying software easier. The solution that works most effectively for applications developed in the Unity ecosystem, and that seems to handle the associated problems best, is Jenkins. It is a relatively flexible tool that is easy to customize to particular needs. Jenkins also requires a virtual or physical machine, facing the same issues as Game CI. However, it is more scalable, allowing integration of multiple devices, both virtual and physical, and is not dependent on a single system.
Other solutions worth mentioning are:
- TeamCity – offering a dedicated Unity plugin and a free On-Premise tier
- CodeMagic – offering a manual for integration with Unity, although with limited capabilities in its free version
| Pros | Cons |
| High flexibility | Requires own servers |
| Relatively easy configuration… | …but requires vast DevOps and Unity expertise |
| High-performance | |
| Free Jenkins and free third-party tiers | |
| Possibility to use both local and virtual servers | |
| Full control over pipelines |
5. Own local computer-server
A physical machine prepared on-site, adapted to actual needs, allowing cost reduction, particularly in smaller projects. The team can prepare their solutions or use previously mentioned options, such as Game CI or Jenkins. In the case of a proprietary solution and own machine, developers have full control over development and costs, are immune to unfavorable changes, and can adjust the direction of development to own needs. At the same time, the team needs to take full responsibility for the solutions’ development, as well as the stability and availability of the service. The biggest problem is the systems’ very limited scalability. If not prepared properly, it won’t allow extending the computational power of the machine beyond what is possible to achieve with a single computer, and creating a satisfactory scalable system requires huge amounts of work. Every extension of computing power requires physical intervention in the machine.
| Pros | Cons |
| Easy access to the machine | Problematic increase of performance |
| Unlimited configuration possibilities | Vulnerability to external threats (lack of power, fire on the premises, etc.) |
| Possibility of integration with ready-made solutions | Vast amounts of work and knowledge needed for configuration |
| Relatively low costs |
What did we choose?
For our AR app, developed under the Nsflow project, we are testing the solution on a local server running Windows 10 and configured GitLab Runner, which is dedicated to our application. The computer has good specifications, sufficient for our needs. Below, we have described a quick step-by-step guide to prepare the CI/CD server in its most basic version:
- In the first step, we configured GitLab Runner ➡ Install GitLab Runner on Windows on the local server and linked it to a given repository on GitLab – as the operating system is Windows, we set PowerShell as shell in config.toml.
- Then, we installed the necessary software: Unity in the appropriate version, Fastlane ➡ Getting started with Fastlane for Android along with AWS CLI dependencies, all necessary dependencies needed to build applications on Hololens augmented reality glasses including Windows SDK in the appropriate version and configured them appropriately (similar to local builds on the developer’s hardware).
- The next step was writing a script in C# on the Unity side, which can be called later using Unity CLI ➡ https://docs.unity3d.com/Manual/EditorCommandLineArguments.html. This allows us to run a build for each platform with proper configuration – for Hololens we used ready-made methods from the UnityPlayerBuildTools class found in Mixed Reality Toolkit. These methods trigger automatically the second part of the build in Microsoft Visual Studio.
- Next, we created gitlab-ci.yaml and included appropriate commands from Unity CLI to run previously written code. We also included rules in response to certain actions. The most important rule is building the application as:
- Development version – and release of the application package on AWS S3 using AWS CLI for testers and deployment of the application for internal testing on Google Play using Fastlane
- Production version – and deployment of the application on the production environment in Google Play and the appropriate place on AWS S3
Each released change is preceded by tests available also from the Unity CLI.
We chose this approach for several reasons:
We faced numerous troubles with building applications for Hololens 2, as very few off-the-shelf solutions support UWP and the very peculiar process of building applications for the Microsoft platform. The chosen solution is the most flexible, as we have full control over
- what operating system the machine is running on
- what version of Unity is installed on it (including the necessary SDK and platform tools)
- what dependencies and additional software will be installed on it (AWS CLI, Fastlane, Windows SDK, etc.).
This allows us to build applications for Hololens without any obstacles, which is often impossible using off-the-shelf solutions. The choice was also driven by the immediately available computer with the appropriate specifications (GPU + CPU), which significantly speeds up development time for both UWP and Android, compared to the builds that we were previously forced to do on our computers. Our current demand for builds is relatively small, and a single machine can meet it. Since it is a physical device, which we can easily access either locally or via “remote desktop”, analyzing and solving problems is much easier than in the case of ready-made solutions.
Unfortunately, there are no perfect solutions, and the one we chose also has its limitations.
What issues do we need to tackle? The major problem is undoubtedly the scalability of this solution. The only possibility to scale our projects is to exchange computer components or extend the system with additional units. The machine must also be connected to a power source and network at all times, so any network connection issues or power supply downtimes prevent us from building applications. We must take full responsibility for the availability and reliability of our solution and its development. We cannot rely on third-party warranties. In addition, using Windows, we are not able to provide application support for Apple devices, so extending the system to support iOS or macOS will involve purchasing and integrating another physical computer running Apple or using an additional virtual machine running Apple.
Still, even facing the listed limitations, our choice is easier than providing support for Hololens 2 using the other proposed solutions. We plan to deploy Jenkins to the current system whenever the need arises to add another operating system or to increase application building performance. This should solve the problems mentioned above.
Is Unity good? Or does it have a justified bad reputation?
Taking into consideration all of the above, do developers form a love-hate relationship with the engine? Or do they all more-or-less secretly wish for a new, more user- and CI/CD-friendly solution to enter the market?
We neither intend to pass judgments nor deal in absolutes. As you’ve already seen above, some of our specialized projects are built using Unity, and despite some inconvenience (or taking detours), the advantages outweigh the disadvantages. If you’d ask us for predictions on Unity’s future and our thoughts on it, we wouldn’t hesitate with admitting that the engine is – and will remain – one of the best tools for developers of (nearly) all platforms, operating real-time 3D content.
Hopefully, its creators will stay on the path towards easier automation, enabling efficient, fluent development and integration of cutting-edge applications. As a solution offering unmatched opportunities coming in handy in augmented, virtual, and assisted reality applications development, Unity needs to incorporate better facilitation of CI/CD pipelines. Only then, the engine will accommodate the needs of developers and ultimately grow beyond the game creation field becoming the perfect solution for AR/VR applications it has the potential to be.
Are you looking for experienced developers to help you with an AR/VR application or other solutions, utilizing 3D models and real-time spatial data? Book your free consultation here. Let’s meet to discuss your idea and see how Unity can help bring your idea to life.
