When deploying to a VM you don't need to build a new image. If setup right you can just copy the updated files over and then trigger a reload or restart of the service. Different team's services are in different directories and don't conflict.
Sane people use Debian, Debian packages are compatible with the Debian release they are from. I do not have to worry about accidentally installing an incompatible deb; even if I try to, apt won't allow me to install a package whose deps cannot be satisfied because they're too new (and thus, not in my release's package repo).
I know other distros have problems with release management, but this is why I've used Debian for the past 20 years and will continue to use Debian
That won't save you if an application requires newer tooling or libraries than whatever is in Debian stable. Once that happens the application needs to bundle its dependencies. But that is precisely why people use containers.
In other words, the technology I have used non-stop since it was mainlined in 2008 is the technology all of you use today. I can deploy a VM, you can deploy a VM, the difference is the API we use to do it, but they're all VMs.
And yes, my VMs are not required to be Debian Stable, and I can deploy any version as needed. That is why we have VMs, so we do not need to dedicate entire machines to a single application with unusual dependencies. Something big companies like Amazon and Google and Microsoft realized is the true wisdom that sysadmins like me have always known: even the damned kernel is a dep that should be tracked, and sometimes this does matter, and the only way you can deploy kernels on a per-application basis is with VMs.
Something container jockeys will never understand: containers that are offered through the OCI facility in the kernel has multiple discrete userlands, but one kernel. You do not have a hypervisor with its own kernel.
Docker, real namebrand Docker, is an OCI consumer. Using something that implements a compatible API is not Docker, but merely a compatibility shim.
Then a developer deploys their "loose files" on top a couple of times, so now you have the image plus god-knows-what.
The VM scale set scales out.
What version of the app is running on which instance?
Answer: Mixed versions.
Rsync is smart enought to figure out how to get parity.
>What version of the app is running on which instance?
There is always going to be a time during a rollout where there are mixed versions running.
Nobody expects a month old version to occasionally turn up and then mysteriously disappear when some rsync job catches up.