Also “management” and “devops” needs to trust every dev to push out a high quality update. Twice daily deploys don’t happen if QA goes through a 48 hour test process for every release.
the devs at factorio have developed an amazing test suite automation system to automate regression tests. I wouldnt be surprised if this is what gives them most of their confidence to do twice daily releases. I thought it was newer, but they seem to have had it for the past 6 years. So i guess my point is they dont need to 100% trust every dev (while I'm sure they could with such a small team) they can instead trust in the tests.
Wait, this went from twice-daily “updates” to release too fast. One is a blog post / tweet, the other is software related ;-) Where did you get twice daily _release_ from?
Mind that the amount of QA you ought to have heavily depends on what game you're making - e.g. with a story heavy game, you 100% want give or take 3 weeks on every update for localization checks, or for a MMO you probably want to run new clients/servers with your testers first for about a week to make sure nothing catastrophic happens, which is especially important in online games(lots of bad PR and real money invested by players - you really don't want to have to roll back "saves").
All depends on budget and quantity of course, but this is what's usually planned for from my personal experience working in that sector.
Not a dev: " Twice daily deploys don’t happen if QA goes through a 48 hour test process".
Why does that matter, surely it's pipelined. If you feed in RC packages to a 48h QA twice daily then after 2 days lag you're getting tested code twice daily.
I'm not suggesting that's realistic for large software houses, just that the logic seems wrong?
I think the QA process isn't usually as pipelineable as you're suggesting. On a website it's often easy to QA changes that happen on page A at the same time you QA changes on page B. But in a game, especially one like factorio, it's probably a lot harder to find features that can be tested and deployed simultaneously with other features.
It would be easy to test changes to the design of Level 3 at the same time as changes to the design of Level 5, but it would be hard to test changes to the way inserters work at the same time as testing changes to the way conveyor belts work.
If the QA cycle is too long the developer gets out of the zone in that area - two days isn’t bad but some places you won’t get review or reports for weeks after submitting code.
CobsterLock|5 years ago
https://www.factorio.com/blog/post/fff-62 https://www.factorio.com/blog/post/fff-186
dstick|5 years ago
nip180|5 years ago
meibo|5 years ago
All depends on budget and quantity of course, but this is what's usually planned for from my personal experience working in that sector.
pbhjpbhj|5 years ago
Why does that matter, surely it's pipelined. If you feed in RC packages to a 48h QA twice daily then after 2 days lag you're getting tested code twice daily.
I'm not suggesting that's realistic for large software houses, just that the logic seems wrong?
simonbw|5 years ago
It would be easy to test changes to the design of Level 3 at the same time as changes to the design of Level 5, but it would be hard to test changes to the way inserters work at the same time as testing changes to the way conveyor belts work.
bombcar|5 years ago