Automating Our Game Release Pipeline
Our upcoming game will be released on multiple store fronts and device families and Operating Systems. Since we will be using Unity and its a cross platform development tool our lives are somewhat easy in terms of developing the game. While it makes our lives easier it’s not as easy as unity makes it sound. While they do technically support build to multiple Operating Systems (Windows, Mac, Linux) and Platforms (PC, XBOX, PlayStation, etc.) it does require some changes for each platform at API level. Some require simple method changes, and some require us to use different rendering packages.
Now if we were to support all stores and operating systems and hardware's we need to make sure some automation is in place. Because manually doing all of these for a small game studio under strict budget is going to be a nightmare. We need to carefully organize our workflow and put automation wherever we can to make our lives easier. Because our focus needs to be in developing the game itself. Thanks to git we are able to setup our project in such a way where
- The base game without any kind of platform dependent code.
- Branches for each platform/store dependent code.
- Sub-Branches for OS-Dependency (if needed)
Our branching looks somewhat like this
Each store comes with their own SDK which is not compatible with other Stores. For simplicity lets just say XBOX and PlayStation is another store. It goes beyond a store but to make things easy to understand lets just stick to that each store requires their own SDK implementation which is exclusive to them. Thankfully for us Unity Handles most of the OS dependency and it’s usually as easy as just changing build target for that OS so we don’t need to have branches for each store.
Our automation actually starts before we even get to our base game branch. It starts in our development branch. To keep the article small and readable I will not be talking about our development rules and pipeline. Lets just say once we make a Pull-Request in the main branch from the dev branch our Build & Manual Q/A process will start. What it will do is,
It will try to create a build from the dev branch.
To create a build obviously it’s going to run the tests first to make sure everything is okay from the code level
If it succeeds to create the build (Windows) it will upload the artifact to a cloud storage and send an email to our Q/A with the download link.
It will also notify our discord channel that a new build has been sent for QA to approve.
Now once again I’d rather skip sharing information about how in depth, we go to keep this short. There’s also a Q/A Branch that might have additional Q/A Tools to validate all systems working at code level. In any case if Q/A fails, Q/A will create a report on why it’s failing and send it back down to developers to fix. Otherwise, we go forward. Only Q/A is allowed to merge the dev to main via branch protection rules thanks to GitHub.
In any case once the merge happens our build pipeline starts. Thanks to GameCI our lives are once again much simpler. They made an open source github action that builds for unity. Forgot to mention we used the same tool to generate the Q/A Build.
In Case you are wondering why we need to have an automatic build pipeline; you probably have no idea how long it takes to build each game. And if you are switching each OS and platform like we need to it may very well take one dedicated developer a day to get the whole thing done, maybe more. Only thing he be doing all day is press 3–4 buttons and wait whole day doing nothing but staring at the screen watching things compile. Not very effective use of anyone’s time.
To make things easy to understand look at the following diagram.
In case you are wondering what tool I used to generate such a diagram, I can’t stress how awesome yEd — Graph Editor is. Give it a look.
Steam Build Pipeline
The CI goes to the Steam Branch that handles Steam related SDK and it’s implementations. It creates three separate matrix builds for each OS(Windows, Mac,Linux). Then it uploads the artifacts to it’s respective depots via Steam Github Action. Once done it emails our store admin to do the rest of the process.
GOG Build Pipline
It’s more or less the same pipeline as steam. They have their own command line tools and even made our lives easier by making Steam API compatible with their store. In any case once it’s done running it sends email to our store admin.
Xbox Build Pipeline
Now this is where things start getting complicated. Firstly, it’s windows only build however it requires us to use a custom Build script. Why? Once you get into it you will know. This whole thing is under NDA so let's skip unnecessary details. But just know we would need a custom build script. Running the script via same GameCI is kinda viable but in a way it’s dumb as they don’t provide us a command line tool that can be used to automate the upload process. However, we can at least get the artifacts. So that’s something. Since we can’t automate this, we probably have to upload the artifact to a drive and send email to store admin to upload and do the rest. This part is still a work in progress.
Now we are delving deeper into console territory. This requires additional QA process as Previous tests were done on PC with KBM but now we need to make sure Controllers work as intended. (we did test controllers on PC) It’s very important to do the tests again. Like before we can write a custom build script to automate the builds which will leave us with an artifact. Once it’s done our Q/A can test console builds and send the store admin once it’s passed. And yes, we need to generate Xbox One and Series builds separately and test on each hardware.
PlayStation Build Pipeline
They are complicating things a bit more. In any case it’s sort of similar to Xbox Console builds we can create a custom build script to build for PlayStation and get an artifact.
References
- GameCI — GitHub Action to Automate Unity Builds
- yEd — Graph Editor — Diagram Drawing tool And it’s Free!
