- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
cross-posted from: https://lemmy.ca/post/73383204
Apparently, Valve keeps getting builds that were never run through Steam at all, which is how games end up with broken launch options or missing depots.
You must log in or # to comment.
They should charge a deposit for reviews. If it’s clearly slop, then the deposit is forfeited. A review is cheap enough that even small-time studios should be able to afford this.
I read the headline and was like they want devs to play Half-life?
I have somehow seen youtube channels of indie devs crashing out over how these are onerous requirements that they will never financially recover from and this means Valve hates indie devs.
While also complaining that their games/updates are taking too long to get actually screened and published.
I have since concluded that those indie devs are hacks, because none of this seems to be unreasonable in anyway.
As 9point6 says… yeah, most of this can pretty easily be handled by adding another step or to to your build automation process, or just, gasp! Do it manually!
Is… is it really that hard to know what your own games dependencies… actually are?
Genuienly ridiculous that Valve has to specifically mandate that uploaded games, you know, need to actually run, don’t crash on launch… the bar is apparently in hell.
smdh
If it’s such a huge chore to play your game, then why did you make it? More than that, why would anyone else play it?
We have plenty of CI that launches and tests our shit. Before any prod deploy, I always take 5-15 min to click around before running the deploy job.
Like… how often are you deploying if you can’t take the 5 min to do that? If you’re a dev you probably already have the environment up and running.
IMO it shouldn’t be merged if it’s not deployable. So same thing you said but test before merging, after merging it should start the deployment process automatically. The idea here is that ease of development/code changes would drive up the quality.
If something gets missed, add it to your acceptance tests, it’s not that common for things to have to have manual deploys. Dave Farley has a lot of content about CI on YT that I recommend watching (even pre-AI becoming popular)
it shouldn’t be merged if it’s not deployable.
100 % agree. The purpose of post-merge testing is to have an extra layer of security to prevent bugs from leaking out into prod, not that you should ever consciously merge something that is not deployable. In my experience, testing on a feature before merge tends to focus on what you expect could be broken/bugged. The post-merge/pre-deploy testing exists to catch cross-feature bugs and in general find the stuff you never expected to break in the first place. Basically: Test your feature thoroughly before merging, then test the whole app without focusing on any particular feature before deploying.
after merging it should start the deployment process automatically (…) it’s not that common for things to have to have manual deploys
There’s two sides to this: We have auto-deploy on merge to a staging environment, and a manual deploy to prod. That lets us keep a high rate of development, while we continuously test / use the staging environment internally. The manual prod deploy doesn’t cost us any extra time, since it essentially consists of clicking the “deploy to prod” button. The advantage is that we typically get a couple days of delay from something hitting staging before it goes to prod, which has let us catch a couple embarrassing bugs before they hit customers. When that happens, we can improve our testing regime without the bug having ever hit prod in the first place.
So basically, before I click the “deploy to prod” button, I spend maybe 15 minutes clicking around in the staging environment to double-check that all is good, then I double-check that we don’t have any known blocking bugs (we just use a dedicated issue-tag for “I found a deploy-blocker on staging, don’t deploy to prod before it’s fixed.”)
That clarifies things. Thought it was more of a babysitting the deployment which would be annoying.
Smoke test them while you got them!
"It works on my machine"itis has hit the indie crowd!!
I was about to say this just saved some test engineers’ jobs
But then realised it’s an easily written post-deploy test automation stage stuck onto the end of the release pipeline
That’ll still fix the problem it’s intending to solve - games that don’t launch
As long as the developer uses a different PC with a different user account name. Otherwise it can still suffer from “it works on my PC” syndrome because they used resources that are local to their device and not included in the game
I’ve not heard of release pipelines running directly on a dev’s own PC before but sure, if they’re running it on their own PC it’s not the best test. It’s still better than not running it at all which sounds like has been happening
deleted by creator
The onions voting simulator wasn’t that bad, come on.
What’s a depot in this context?
According to SteamWorks Documentation: A depot is a logical grouping of files which are all delivered to a customer as a single group.
In the simple case, that’s probably an EXE and some DLLs plus maybe some graphics/music/etc. files (if they’re not packed into the EXE) for a particular version of the game.
Great!
I would trust my pipelines that much
