Valve now requires developers to launch their game through the Steam client and run it for at least five minutes before submitting it for review, as part of several new additions to Steam's pre-release checklist. It doesn't have to be the developer playing, since anyone's playtime counts, as long...

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.

  • Trilogy3452English
    1·
    8 hours ago

    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)

    • thebestaquamanEnglish
      2·
      4 hours ago

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