Building and Publishing Games to Steam Directly from GitHub Actions
nullonerror.org
nullonerror.org
However, there is a caveat regarding the workflow code itself, that placing "run" statement with specific commands directly in YAML may make it difficult to debug locally. I would recommend that "run" statements be only for script execution and their number minimized. This way, scripts can be run locally without waiting for the entire CI pipeline to execute each time.
Doesn't that effectively defeat the purpose of 2FA?
Personally, I feel like I'd automate it in a way that everything up until that point is automated, but the actual "release" (upload really) to Steam would be in a different step that asks for the 2FA every single time, on purpose, so I actually get the benefits of a 2FA together with automating most of the pipeline while still having control of the final release.
Yes and No. You need to 2FA in the first place to get the credentials in place. After that it's just basic secrets management - your steam credentials are no more or less secure than your playfab developer secret that you use to upload servers, or the credentials that you use on your AWS machine to do the deploy.
There's no way to generate a service token for steam that says "this is allowed to deploy builds only", like a gha token, or an AWS credential. Both of those require you to 2FA to generate the token in the first place. Ultimately, if steam really cared about security they would allow for something like this, like every other modern provider does. But they haven't exactly kept up with "modern" best practices.
> Personally, I feel like I'd automate it in a way that everything up until that point is automated, but the actual "release" (upload really) to Steam would be in a different step that asks for the 2FA every single time, on purpose, so I actually get the benefits of a 2FA together with automating most of the pipeline while still having control of the final release.
You can't upload builds above a certain size manually to steam, you need to use steamcmd. Steam isn't just for releasing public builds, we use it for playtesting for example. So our CI uploads versions of our game to private betas on steam for our team to be able to jump into, like a staging environment. Requiring a manual step for that in another tool, with another set of credentials and scopes to manage is a bigger risk (IMO) than managing an extra secret. If you do these steps as manual steps but make the "release" step a manual step, then you've introduced a massive untested failure point in your deployment pipeline that happens at the latest possible moment. If you have servers to manage, or clients on another storefront (Epic, GoG, PSN/Xbox) you need to ensure versions are coordinated; and now you're potentially asking someone to log into 5 dashboards to set manually upload versions and set builds.
There's no reason games should be exempt from CICD best practices, IMO.
Yeah, I'm not arguing for multiple approvals to deploy a suite of things, but one approval which is authenticated for doing it all, nor am I arguing to somehow add more authentication on top of what you already have, you'd obviously aim for one integrated process.
But regardless, I hear your point and agree with lots of other things you wrote.
And that integrated process in a world where you ahve multiple providers (Steam, PSN, Xbox) is likely your CI provider. As long as the token generation is correct, and you treat the vdf files like any other build secrets, it's no worse than GHA being able to deploy to AWS and having 2FA on your AWS console access.
If you read through the actual pipeline, you'll see it's not just "drop a zip file and press a single button". Firstly, you're missing everything that goes before even having a ZIP file, making that process reproducible is valuable regardless of what you do later. Secondly, doing this for three platforms would mean repeating the same thing three times, in slightly different ways. Automating it just makes sense at that point.
Overall, building and publishing a game via automation just brings about every benefit from CI/CD, just to a "game development" context instead, so you'd do it for the same reason you'd automate any software release process.
1. You won't forget how to ship a release if you go months between releases
2. You won't make mistakes when you release code - forgetting a crucial step along the way for example
3. Related: you can add tests to your release process - so your release doesn't go out if you made some last-minute mistake that broke the build
4. You'll release more often: the automation has de-risked your release process and reduced friction around it, which means you can ship with more confidence and less ceremony
5. You can reliably share that release process with other collaborators - not end up in a situation where only one person's laptop is able to ship
6. If your laptop breaks or gets stolen it won't harm your ability to release software
All of the above are true for non-game projects, I don't see why they shouldn't apply to games as well.
https://www.wiechtig.com/blog/clickops-is-the-worst/
https://www.lastweekinaws.com/blog/clickops/
https://blog.equinix.com/blog/2022/12/01/what-is-clickops-an...
Essentially you gain access to a private game on Steam with one or more Steam opt-in betas, to test different branches. It's common to use a CI system to build and then deploy to a steam beta branch.
The process of doing that is, however, a little bit... raw.