Game Build CI/CD Pipeline Setup

Setting Up CI/CD Pipelines for Game Builds

Manual build of Unity project on developer's local machine is not a pipeline—it's a risk. Build depends on local environment settings, editor version, imported caches. "Works for me" becomes "but not for QA, because different script version or different shader cache there".

CI/CD in game dev solves a concrete problem: every commit to develop branch automatically builds into reproducible artifact—build for specific platform. QA always tests fresh build, not dependent on programmer.

GameCI as Unity CI/CD Foundation

GameCI (game.ci)—open Docker image with pre-installed Unity, specifically for CI/CD. Works with GitHub Actions, GitLab CI, CircleCI, Jenkins. Supports all Unity versions from 2019.4 LTS, all target platforms (Android, iOS, WebGL, Windows, macOS, Linux).

Basic GitHub Actions workflow for Unity Android build:

- name: Build Android
  uses: game-ci/unity-builder@v4
  env:
    UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
    UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
    UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
  with:
    targetPlatform: Android
    unityVersion: 2022.3.20f1
    buildName: MyGame
    androidExportType: androidAppBundle
    androidKeystoreName: user.keystore
    androidKeystoreBase64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
    androidKeystorePass: ${{ secrets.ANDROID_KEYSTORE_PASS }}
    androidKeyaliasName: ${{ secrets.ANDROID_KEY_ALIAS_NAME }}
    androidKeyaliasPass: ${{ secrets.ANDROID_KEY_ALIAS_PASS }}

Critical moment—Unity License on CI machine. Unity Personal/Plus requires seat activation. For CI we use either Unity License Server (Enterprise), or manual activation via game-ci activation workflow. This is first stumbling block—without proper activation CI simply won't start.

iOS Build in CI—Separate Story

iOS builds require macOS with Xcode. GitHub Actions provides macos-latest runner, but expensive in minutes. Alternatives: Mac mini in cloud (MacStadium, AWS EC2 Mac), self-hosted runner on physical Mac in office.

Chain for iOS: Unity build → Xcode project (.xcodeproj) → Fastlane gym → .ipa → Fastlane pilot (TestFlight). Fastlane handles certificate signing via match (certificates stored in encrypted git repository) or via Manual Provisioning Profile loaded in CI secrets.

Without signature automation every iOS build requires manual actions in Apple Developer Portal. With Fastlane match—certificate and provisioning profile regeneration is automatic.

Pipeline Structure for Game Project

Proper CI/CD for game consists of several stages:

Validation stage—quick checks without full build: unit tests via game-ci/unity-test-runner, code format check, Asset Database integrity. Runs on every push, takes 5–10 minutes.

Build stage—full build for target platforms. Runs on merge to develop or by schedule (nightly builds). Android: 15–40 minutes. iOS: 30–60 minutes. WebGL: 10–25 minutes.

Distribution stage—after successful build: Android AAB → Google Play Internal Testing via fastlane supply, iOS IPA → TestFlight via fastlane pilot, WebGL → S3/CDN hosting. QA gets Slack notification with direct test-build link.

Production release stage—manual trigger (manual approval). Final build with production config, signed with production keystore/certificate, published to store.

Self-Hosted Runner vs Cloud CI

For studio with 3+ developers, self-hosted runner on dedicated machine is economically favorable. Unity build is CPU and I/O intensive task. Time on GitHub Actions (4 CPU, 16 GB RAM)—40 minutes for Android build. On dedicated server (16 CPU, 64 GB RAM)—same 12 minutes.

Unity Shader Cache and Asset Import Cache between builds—critical for speed. On self-hosted runner cache persists between runs. On cloud CI need explicit caching via actions/cache (Library/ folder), otherwise every build imports all assets from scratch.

Real case: studio 4 programmers + 2 artists, Android project. Manual build took 50+ minutes, done once a week. After setting up GameCI + GitHub Actions on self-hosted Ubuntu runner with Wine for Unity: automatic build on every merge to develop, build time 18 minutes, QA gets Firebase App Distribution link automatically. Bugs caught before release tripled—simply because QA started testing regularly.

Cost calculated after analyzing infrastructure and target platforms.