319
Steam Wants Devs to Play Their Games For At Least 5 Minutes First (www.techpowerup.com)
submitted 5 days ago by to c/nottheonion@lemmy.world
18 comments fedilink hide all child comments
 

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 are viewing a single comment's thread
view the rest of the comments
[–] 107 points 4 days ago* (5 children)

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

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] 30 points 4 days ago (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 4 points 4 days ago (2 children)

    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)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 4 days ago* (last edited 4 days ago) (1 child)

    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.")

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •