Unity to Steam – Part 1 – A useful CI/CD pipeline
How much time do you spend each week testing your game ? How many time you try to build (maybe fail), package the whole thing with the Steamworks tool, wait for the upload then activate the branch on the Steamworks website ?
Pretty annoying right ?
We did have the same process and because we’re a team of 5, it was challenging to manage the different builds (develop, beta, production) with always the same build settings.
To avoid this, we wanted to fully automate the build process from Git update to Steam build availability. It is in place now for more than a month and we wanted to share this work with you.
What is CI/CD ?
CI/CD stands for Continuous Integration / Continuous Deployment is described by Wikipedia like this :
"CI/CD bridges the gaps between development and operation activities and teams by enforcing automation in building, testing and deployment of applications. Modern day DevOps practices involve continuous development, continuous testing, continuous integration, continuous deployment and continuous monitoring of software applications throughout its development life cycle. The CI/CD practice or CI/CD pipeline forms the backbone of modern day DevOps operations."
In other words: each time you consider that your code is stable, the final build is deployed automatically somewhere, ready to be tested or played under real conditions.
This process save the dev team a lot of time and mistakes:
- they don’t think about the deployment pipeline, they just focus on “my code is stable, I validate it”
- the pipeline build the software using the same methods and parameters each time: no more “oops I forgot this step”
- your team do not discover that some code prevents the build to complete 15min before the planned public release
As you can see, there are a bunch of advantages to go with this automatic CI/CD process. However when it comes to Unity + Steam, it is not a trivial tasks and the lack of example and tutorial on the Internet is huge.
Let’s have a look about what it takes.
The process is totally hardware free. Everything is executed on the cloud(s) so you don’t have to care about resource availability and network connection stability.
The process can be illustrated like this:
In order to have this full automated continuous integration process working, you will need:
- a Bitbucket repository
- a Unity Cloud Build licence (through Unity Plus or higher licence or a Unity Teams licence)
- an Amazon (AWS) enabled account
- a Steamworks account with an existing app
The development environment
First of all, let’s have a look to the development environment we have in place here at Polycorne.
This setup is linked to common development process and architecture. Having three environments is necessary because it’s the way to secure your different development steps.
- Develop is a branch dedicated to developers. It is the more alive environment. Changes are pushed here every days.
- Beta is a partially quality validated branch. This one is exposed to the players but they have to manually switch to this branch in Steam if they want to use it: some bugs may cause the game to be unplayable and the player must be aware of this. In exchange they have access to the new feature in advance. Changes are pushed every weeks.
- Prod is the final branch. Once the QA process is done, the fixed beta branch usually become the prod branch. Changes are pushed every 2 weeks or every month.
As you can see, these environments do not have the same update pace and therefor must have parallel tracks inside every tool we use. We need one pipeline for each environment and many subpipelines as illustrated with the picture below:
Keep these names in mind, we will use them during this tutorial.
Let’s start the configuration.