[kqr]

Really? I challenge you to find any items other than 7 and perhaps 8 that don't apply to the types of development you mention.

Essentially the only thing that's different with the types of development you mention is that "final deployment to production" looks different, as it usually involves more or less physically transporting artifacts to your customer.

But the rest is just the same. You should be doing trunk-based development, practise something like code review, gate on integration tests, feature flag, spin up virtual production clones, etc.

In other words, the fact that getting software to your end users is a clumsy process does not preclude you from doing every other step of the process with short feedback loops.

[maccard]

Using distributed version control isn't applicable to most people working in games.

9) is also debatable - requiring someone to clone the entire application to make an infra change to a testing environment.

Adding tickets to commit messages isn't necessarily a requirement - some work (at least in my area) is prototypey and maybe ill defined (the task might be to define it).

Being able to deploy from your own machine is a double edged sword; the situation you need this is an absolute last resort. Enabling deployments from dev machines means credentials to environments, write access to infra, and likely skirting around normal processes.

[KronisLV]

> Using distributed version control isn't applicable to most people working in games.

Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio.

Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/

Unity also seems to be pushing their Plastic SCM as well for this more specialized use case: https://www.plasticscm.com/

Either way, not using version control for any collaborative project is just asking for issues.

Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.

[maccard]

> Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio.

Yes, and I never said you shouldn't use version control , simply that distributed version control isn't necessarily applicable (which is what the claim is).

> Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/

Let's be honest, LFS is duct tape on a pig. It doesn't support SSH, for one. Mirroring a repository is mired with landmines, and probably most importantly it breaks the decentralised model of git by centralising the storage of your binary data.

> Either way, not using version control for any collaborative project is just asking for issues.

Which is not what I said, at all. The article says _distributed_ version control.

> Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.

By distributed version control you mean git here, right? The advantage of git isn't it's technical merit, or the advantages of DVCS (particularly if you're using something like LFS which turns it into a centralized VCS). The advantage of git is that it's well supported in many tools (ci, merge bits, code review, deployment, package managers). Frankly, my experience is the complexity brought on by git (which is quite a few years using it along side perforce and more recently plastic) often outweighs the benefits over something like perforce, particularly on large repos.

[marcosdumay]

What?

#2 and #5 exist only to support #7.

#4 usefulness is completely dependent on the context.

#9 is a joke, right? It's an anti-pattern for most of the web based SaaS applications, and poisonous to anything that isn't SaaS.

And #12... Try that in a large regulated company and people may quite as well end up in jail.

[kqr]

#2 is to improve quality, shorten feedback loops, and simplify merges. You get those benefits whether or not you're able to push things to your customer at will.

Both #2 and #5 really just set a quality bar high enough to reduce long-term maintenance costs. I don't see why you wouldn't want that in a non-web scenario.

#12 is not talking about deploying to production, and I don't see why you shouldn't be able to deploy to a dev environment from your machine. It's nice not to have to run everything locally. Even for non-EU companies.

So aside from #9 which is of questionable utility for any type of development, no, I'm not convinced you've pointed valid examples.