[grhmc]

Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization. It also doesn't "cover up" broken build scripts.

Our build scripts get tested a dozen times a day and cannot tolerate half-assed broken build scripts.

Our deployment pipeline (after verifying the image is good enough to be deployed) packs the docker image into a machine image along with several other containers. The machine image is then deployed to staging. If the machine image passes staging, it goes to production. If there is an issue which has hit production exclusively (it has happened only a handful of times,) it is simply an issue of rolling back to the previous machine image.

[grhmc]

It is far easier and less risky to only run it once and use that artifact than to make sure every environment it could possibly build in is identical. Keeping all your environments perfectly identical is more likely to either: 1. introduce subtle differences you aren't even aware of, or 2. introduce DLL-hell at datacenter scale.

[crdoconnor]

>Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization.

Well, it gets you a step closer to accurately mimicking production.

>It also doesn't "cover up" broken build scripts.

That seems to be what that 'build once' rule is for. If your building process isn't risky, why the need to prohibit running it twice?

[josegonzalez]

So that your build process is faster. If I can use the same container for local dev, continuous integration, staging, and production, that means I only had to build it once and the pipeline to get something from a developer's laptop to a production instance is much quicker.

Just because I can install the operating system doesn't mean I want to do this on every deploy of an application.