(Image credit: midjourney)
Trunk What?
Trunk Based Development (TBD) is committing small, frequent code-changes either directly to main...
For further actions, you may consider blocking this person and/or reporting abuse
Love how dynamic this makes the deployment process. Also that it embraces that error are OK and can be fixed. This gate keeping we have with PRs often feels like perfectionism.
I am suffering from Change Approval Boards, as you so accurately put it, and agree, most of the time the peeps are too far away from what I am doing to truly understand the list of changes.
Anyone not closely involved with the concepts behind my PR will only be able to comment on form, which is a whole different monster which fuels my imposter syndrome.
Besides the automatic test, do you also combine this with user tests? Not sure what your needs are, but for games I could imagine that this would mean we needed more in-person game testing rounds.
Could not agree more on external reviewing, it's a net-negative every time.
I started my career in gaming, and I found it a difficult space to remain agile in because every feature can impact the whole. It's so much art intersecting with tech it was difficult to preserve simplicity.
But I don't think the point of test-automation is to test everything. A lot of release-processes guard themselves behind heavy end-to-end testing, with humans meticulously going through every screen and clicking every detail before a change is brought to production. And it's the wrong response. It's like an autoimmune disease where the life-giving response is out of proportion and mistargeted. Hiding behind thicker and thicker armor weighs down the processes until the product suffocates.
I think it's very important to ambitiously imagine how a process would look if anchored around releasing code both quickly and safely. Because the research also show that speed and quality go hand in hand: High performing teams are both faster and safer than other performance-groups. What would that look like in games? If the game is long-lived and will be iterated on, then perhaps feature toggles could allow changes to be deployed instantly and then progressively rolled out? It would eliminate things like separate builds for user tests, and probably most changes are improvements that can be rolled out automatically.
I of course don't know your context and I've been out of games for a decade now so regardless my knowledge is likely out-of-date, but I hope there are many exciting ways to reimagine developments because otherwise games will miss out on some really amazing gains in job satisfaction, business impacts, and more.
And thanks for reading!
True, safeguarding is not the point here.
Feature flags and roll-outs are some safety measures we employ as well. If a bug is discovered in the rollout it can indeed be fixed quickly.
Something we found is helpful though is when the team play tests the game regularly or are playing the rollout. Not as testers running endless test scenarios but as players. The advantage is that the team understands the user perspective which improves decision making during development which in turn has an impact on development time.
Thank you for taking the time to answer in such detail!