🏁 Lesson 8.4: A Tested, CI-Built Release — and Where to Go Next

What We're Shipping

The goal of this mini-project isn't a big game — it's a pipeline. We'll take a tiny piece of game logic, put it under test (Lesson 8.1), drive it through a build script (Lesson 8.2), gate that build on the tests in CI (Lesson 8.2), and finally walk it through the disciplined checklist that turns "a build" into "a release." By the end you'll have the exact skeleton a studio uses, sized down to fit one lesson.

Here's the whole release, drawn as the checklist we'll execute:

Step 1 — The Tests

We'll ship a trivial but real slice: a WaveConfig that computes how many enemies spawn in a wave. Pure logic, so it's an Edit Mode test. In your Game.Runtime assembly:

namespace Game.Runtime
{
    public static class WaveConfig
    {
        // Wave 1 spawns baseCount; each wave adds 'growth' more, capped at maxCount.
        public static int EnemiesForWave(int wave, int baseCount, int growth, int maxCount)
        {
            int raw = baseCount + (wave - 1) * growth;
            return System.Math.Min(raw, maxCount);
        }
    }
}

And its tests, in a Test Assembly (the asmdef with the TestAssemblies reference from Lesson 8.1):

using NUnit.Framework;
using Game.Runtime;

public class WaveConfigTests
{
    [Test]
    public void FirstWave_UsesBaseCount()
    {
        Assert.That(WaveConfig.EnemiesForWave(1, 5, 3, 30), Is.EqualTo(5));
    }

    [Test]
    public void LaterWaves_GrowLinearly()
    {
        // wave 4: 5 + 3*3 = 14
        Assert.That(WaveConfig.EnemiesForWave(4, 5, 3, 30), Is.EqualTo(14));
    }

    [Test]
    public void Growth_IsCappedAtMax()
    {
        Assert.That(WaveConfig.EnemiesForWave(50, 5, 3, 30), Is.EqualTo(30));
    }
}

Run them in the Test Runner (Lesson 8.1) and confirm three green checks. This is stage 3 of the checklist, proven locally before anything ships.

Step 2 — The Build Script

Now the build entry point from Lesson 8.2, extended with the release-time settings that make it a release build rather than a dev one — versioning, IL2CPP, and managed stripping:

using UnityEditor;
using UnityEditor.Build.Reporting;
using UnityEngine;

public static class ReleaseBuild
{
    // -executeMethod ReleaseBuild.Perform
    public static void Perform()
    {
        // --- Stage 1: version stamp (from CI env, with fallbacks) ---
        string version = System.Environment.GetEnvironmentVariable("BUILD_VERSION") ?? "1.0.0";
        string run     = System.Environment.GetEnvironmentVariable("GITHUB_RUN_NUMBER") ?? "0";
        PlayerSettings.bundleVersion = version;

        // --- Stage 5: release backend + stripping ---
        var group = BuildTargetGroup.Standalone;
        var named = UnityEditor.Build.NamedBuildTarget.Standalone;
        PlayerSettings.SetScriptingBackend(named, ScriptingImplementation.IL2CPP);
        PlayerSettings.SetManagedStrippingLevel(named, ManagedStrippingLevel.High);

        string[] scenes = System.Array.ConvertAll(
            System.Array.FindAll(EditorBuildSettings.scenes, s => s.enabled),
            s => s.path);

        var options = new BuildPlayerOptions
        {
            scenes = scenes,
            locationPathName = $"Builds/Win64/MyGame-{version}-{run}/MyGame.exe",
            target = BuildTarget.StandaloneWindows64,
            options = BuildOptions.None    // no Development flag = a real release build
        };

        BuildReport report = BuildPipeline.BuildPlayer(options);
        bool ok = report.summary.result == BuildResult.Succeeded;
        Debug.Log(ok ? $"Release {version}+{run} built" : "Release build FAILED");
        EditorApplication.Exit(ok ? 0 : 1);   // exit code gates CI (Lesson 8.2)
    }
}

Step 3 — The CI Workflow

Wire it together with the GitHub Actions workflow from Lesson 8.2, now triggered by a tag so a release runs only when you deliberately tag a commit (stage 4), and passing the version through to the build:

name: Release
on:
  push:
    tags: [ 'v*' ]          # runs only on version tags like v1.0.0

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { lfs: true }

      - name: Tests
        uses: game-ci/unity-test-runner@v4
        env: { UNITY_LICENSE: '${{ secrets.UNITY_LICENSE }}' }
        with: { testMode: editmode }

      - name: Build
        uses: game-ci/unity-builder@v4
        env:
          UNITY_LICENSE: '${{ secrets.UNITY_LICENSE }}'
          BUILD_VERSION: '${{ github.ref_name }}'   # the tag, e.g. v1.0.0
        with:
          targetPlatform: StandaloneWindows64
          buildMethod: ReleaseBuild.Perform

      - name: Upload versioned artifact
        uses: actions/upload-artifact@v4
        with:
          name: MyGame-${{ github.ref_name }}
          path: build/

Push a tag and the pipeline runs: check out → tests (green, or the release stops) → IL2CPP release build → versioned artifact. Stages 3, 5, and 6 of the checklist now happen automatically, every time, from a clean machine.

💡 Tag-triggered releases are a deliberate gate. Ordinary pushes can run a lighter test-only pipeline; the heavy release build fires only on a v* tag. That separation keeps everyday CI fast while making an actual release an explicit, traceable act.

Step 4 — The Release Checklist

The tooling is built; releasing is now walking Figure 1. Do it in order, top to bottom:

1. Version bump. Decide the version (semantic: MAJOR.MINOR.PATCH). Our script stamps it from the tag.
2. Quality & Player settings. Confirm the release quality level, that the right scenes are enabled in Build Settings, and icons/name/company are set.
3. Tests green. Run the full suite locally first — never tag on red. The Test Runner is the gate (Lesson 8.1).
4. Tag the commit. git tag v1.0.0 && git push --tags. This exact commit is now the source of record for the release.
5. CI build. The tag triggers the release workflow: IL2CPP, high stripping, tests re-run on a clean checkout.
6. Versioned artifact. CI uploads MyGame-v1.0.0; upload symbol files for crash symbolication (Lesson 8.3).
7. Smoke test. Download the artifact onto a clean machine, install it, and play the happy path — especially watching for anything stripping may have broken. If it fails, fix and re-run (the dashed loop).
8. Release. Promote the smoke-tested artifact to testers or the store channel. Then — Lesson 8.3 — watch analytics and crash reports roll in.

What You Built

Extend it: add a Play Mode smoke test that boots the main scene in CI; add a WebGL target to the build matrix and deploy the artifact to a static host; wire symbol upload into the workflow; add a second job that only runs Edit Mode tests on every push (fast) while the release job runs on tags (heavy). Each is a small, well-scoped addition to a pipeline you now understand end to end.

🚀 Where to Go Next

This course was, by design, focused and deep rather than broad. It picked four pillars — Performance/DOTS, Rendering, Netcode, and Tooling/Pipeline — and went as deep as one course reasonably can. That means whole territories were left for you to explore. Here's the map.

Two big topics this course deliberately left out

The next frontier of each pillar you already know

• Performance & DOTS → You learned entities, components, systems, and baking. Next: Unity Physics (the stateless, DOTS-native physics engine), Netcode for Entities (networking at ECS scale, a different stack from the Netcode for GameObjects you learned in Module 6), and the deeper corners of the Job System — custom IJobEntity chunking and cache-line-aware data design.
• Rendering → You wrote HLSL, a Scriptable Renderer Feature, and compute shaders on URP. Next: authoring a fully custom Scriptable Render Pipeline from scratch, advanced RenderGraph passes, and — if your project demands cinematic fidelity — the High Definition Render Pipeline (HDRP) with its physically-based, volumetric feature set.
• Netcode → You built an authoritative prototype with NetworkVariables and RPCs. Next: client-side prediction and server reconciliation, lag compensation, dedicated server hosting (Unity's Game Server Hosting / Multiplay), and the wider UGS multiplayer stack — Lobby, Relay, and Matchmaker.
• Tooling & Pipeline → You built EditorWindows and used Addressables locally. Next: remote Addressable content served from a CDN with content catalogs and live updates, full UI Toolkit runtime UIs, and richer editor automation — asset post-processors, custom build pipelines, and package authoring.

Hands-on Challenge

The Finish Line

🚀 What's Next?

That's the whole course. Your next step is out there in your own project — pick a direction from the map above and start. Thank you for coming this far; it's been a genuine pleasure teaching you.